I am using Red Hat Enterprise 6.3 and I have just mounted a new volume in one folder of my preference.

After reboot that mount point was lost and the volume was mounted at his original place.

In which place I can set my mount call so that I can have my volume always at the same place? Do I have to look at init.d or is there a better place?

/etc/fstab is the traditional configuration file to define permanent mounts.

Check more discussion of this question.

I’m using below command to transfer files cross server

scp -rc blowfish /source/directory/* username@domain.net:/destination/directory

Is there a way to transfer only files modified files just like update command for cp?

rsync is your friend.

rsync -ru /source/directory/* username@domain.net:/destination/directory

If you want it to delete files at the destination that no longer exist at the source, add the --delete option.

Check more discussion of this question.

I’m helping to teach two Unix courses next week. Users will be granted an account on a RHEL 5 machine, during which time they’ll add files to their /home folder, update their .bashrc and other dotfiles, and perform other general messiness that needs to be cleaned up.

Students in the second session will be reusing the user accounts of the folks in the first session. I’d like to automate the cleanup of their accounts, so new users can start fresh.

I’m sure I could write a shell script that runs a su -u $USER_ID and lays down an “original” set of good files in their homedir, and removes anything else it finds. Are there other tools that will help me with this clean/reset operation? I don’t have any experience with Puppet, Chef, or other tools. Would they be helpful to do something like this?

To provide a scope of the problem, there’s about 30 user accounts, I know all the userid/passwords, and they’re all created on the same RHEL box.

There are many ways that would help:

• remove the complete home directory and copy all files from /etc/skel back to the homedir. Change permissions afterwards.
• put the system in a virtual machine, make a snapshot and revert to the snapshot after lesson 1
• find something like a kiosk mode in RHEL. Ubuntu has something like that, which automatically restores the home during logoff
• put the home on a btrfs filesystem, make a snapshot and revert after lesson 1
• tar the home dir before lesson, delete home afterwards, restore from tar
• …

And learning other tools like Puppet/Chef is a little bit too much if you want results next week.

Check more discussion of this question.

Is there any reason why I would want to have

iptables -A INPUT -j REJECT

instead of

iptables -A INPUT -j DROP

As a general rule, use REJECT when you want the other end to know the port is unreachable’ use DROP for connections to hosts you don’t want people to see.

Usually, all rules for connections inside your LAN should use REJECT. For the Internet, With the exception of ident on certain servers, connections from the Internet are usually DROPPED.

Using DROP makes the connection appear to be to an unoccupied IP address. Scanners may choose not to continue scanning addresses which appear unoccupied. Given that NAT can be used to redirect a connection on the firewall, the existence of a well known service does not necessarily indicate the existence of a server on an address.

Ident should be passed or rejected on any address providing SMTP service. However, use of Ident look-ups by SMTP serves has fallen out of use. There are chat protocols which also rely on a working ident service.

Check more discussion of this question.

I’ve been given by a company their FTP IP where I should connect to. I got also username and password. That is supposed to work with port 21, right?

I tried to use FTP command-line but it didn’t work; I tried my chance with sftp command-line and, using their credentials, I am authorized and connect without any problem.

SFTP is supposed to use port 22 (and I used wireshark to check that).

Am I right that this is just luck? I feel a bit confused.

I am using LINUX CentOs 6.4.

The company may only allow SFTP, they don’t have to allow both. They are two different protocols, SFTP being the SSH File Transfer Protocol and really isn’t related to FTP much. This is keeping it extremely simple, differences between the two are beyond the scope of this question.

It’s possible they didn’t specify that you should use SFTP and not FTP, assuming they’re the same. Most FTP clients I’ve used don’t automatically try port 22 by default, you have to tell them.

Basically they’ve given you ssh access to their server, whether this was accidental or not I can’t tell you.

Check more discussion of this question.

Recent versions of RHEL/CentOS (EL6) brought some interesting changes to the XFS filesystem I’ve depended on heavily for over a decade. I spent part of last summer chasing down an XFS sparse file situation resulting from a poorly-documented kernel backport. Others have had unfortunate performance issues or inconsistent behavior since moving to EL6.

XFS was my default filesystem for data and growth-partitions, as it offered stability, scalability and a good performance boost over the default ext3 filesystems.

There’s an issue with XFS on EL6 systems that surfaced in November 2012. I noticed that my servers were showing abnormaly-high system loads, even when idle. In one case, an unloaded system would show a constant load average of 3+. In others, there was a 1+ bump in load. The number of mounted XFS filesystems seemed to influence the severity of the load increase.

System has two active XFS filesystems. Load is +2 following upgrade to the affected kernel.

Digging deeper, I found a few threads on the XFS mailing list that pointed to an increased frequency of the xfsaild process sitting in the STAT D state. The corresponding CentOS Bug Tracker and Red Hat Bugzilla entries outline the specifics of the issue and conclude that this is not a performance problem; only an error in the reporting of system load in kernels newer than 2.6.32-279.14.1.el6.

WTF?!?

In a one-off situation, I understand that the load reporting may not be a big deal. Try managing that with your NMS and hundreds or thousands of servers! This was identified in November 2012 at kernel 2.6.32-279.14.1.el6 under EL6.3. Kernels 2.6.32-279.19.1.el6 and 2.6.32-279.22.1.el6 were released in subsequent months (December 2012 and February 2013) with no change to this behavior. There’s even been a new minor release of the operating system since this issue was identified. EL6.4 was released and is now on kernel 2.6.32-358.2.1.el6, which exhibits the same behavior.

I’ve had a new system build queue and have had to work around the issue, either locking kernel versions at the pre-November 2012 release for EL6.3 or just not using XFS, opting for ext4 or ZFS, at a severe performance penalty for the specific custom application running atop. The application in question relies heavily on some of the XFS filesystem attributes to account for deficiencies in the application design.

Going behind Red Hat’s paywalled knowledgebase site, an entry appears stating:

High load average is observed after installing kernel
2.6.32-279.14.1.el6. The high load average is caused by xfsaild going into D state for each XFS formatted device.

There is currently no resolution for this issue. It is currently being
tracked via Bugzilla #883905. Workaround Downgrade the installed
kernel package to a version lower then 2.6.32-279.14.1.

(except downgrading kernels not an option on RHEL 6.4…)

So we’re 4+ months into this problem with no real fix planned for the EL6.3 or EL6.4 OS releases. There’s a proposed fix for EL6.5 and a kernel source patch available… But my question is:

At what point does it make sense to depart from the OS-provided kernels and packages when the upstream maintainer has broken an important feature?

Red Hat introduced this bug. They should incorporate a fix into an errata kernel. One of the advantages of using enterprise operating systems is that they provide a consistent and predictable platform target. This bug disrupted systems already in production during a patch cycle and reduced confidence in deploying new systems. While I could apply one of the proposed patches to the source code, how scalable is that? It would require some vigilance to keep updated as the OS changes.

What’s the right move here?

• We know this could possibly be fixed, but not when.
• Supporting your own kernel in a Red Hat ecosystem has its own set of caveats.
• What’s the impact on support eligibility?
• Should I just overlay a working EL6.3 kernel on top of newly-build EL6.4 servers to gain the proper XFS functionality?
• Should I just wait until this is officially fixed?
• What does this say about the lack of control we have over enterprise Linux release cycles?
• Was relying on an XFS filesystem for so long a planning/design mistake?

Edit:

This patch was incorporated into the most recent CentOSPlus kernel release (kernel-2.6.32-358.2.1.el6.centos.plus). I’m testing this on my CentOS systems, but this doesn’t help much for the Red Hat-based servers.

At what point does it make sense to depart from the OS-provided kernels and packages when the upstream maintainer has broken an important feature?

“At the point where the vendor’s kernel or packages are so horribly broken that they impact your business” is my general answer (coincidentally this is also about the point where I say it makes sense to start looking at ways to depart from the vendor relationship).

Basically as you and others have said, RedHat seems to not want to patch this in their distributed kernel (for whatever reason). That pretty much leaves you in the situation of having to roll your own kernel (keeping it up to date on patches yourself, maintaining your own package and installing it on your systems with Puppet or similar, or running a package server that Yum or whatever they use today can reference), or taking your marbles and going home.

Yes I know taking your marbles and going home is often an expensive proposition — switching OS vendors is a huge pain, especially in the Linux world where the flavors are radically different from an administrative standpoint.
Other options like going totally CentOS are also unappealing (because you lose support, and you’re still getting essentially RedHat’s code built by someone else so you’d still have this bug).

Unfortunately unless enough people (i.e. “huge companies) take their marbles and go home the vendor won’t care so much about screwing people over by shipping bad code and not fixing it.

Check more discussion of this question.

I have this file in my linux machine:

 ----------9976723563nneh4_-----192.9.200.4

I try to delete this file but I cant as all see here:

what need to add to rm in order to remove this file ?

rm "----------9976723563nneh4_-----192.9.200.4"
rm: illegal option -- --------9976723563nneh4_-----192.9.200.4
usage: rm [-fiRr] file ...

.

rm '----------9976723563nneh4_-----192.9.200.4'
rm: illegal option -- --------9976723563nneh4_-----192.9.200.4
usage: rm [-fiRr] file ...

rm -- ----------9976723563nneh4_-----192.9.200.4

You need -- in order to tell rm (and more or less all other GNU software) that all following parameters are file names even when beginning with “-”. Otherwise (and in your case) the file name is confused with options. Another possibility is

rm ./----------9976723563nneh4_-----192.9.200.4

Check more discussion of this question.

I want to monitor all user’s activity in my server.

Even when the user executes a shell command from some editor like vim I want to
see them in the log file.

I have checked the tool acct but it is not listing the complete commands.
(Please correct me if I have missed some options which does already).

Which Linux tool I should be looking at to solve this problem?

Add this line to your pam config responsible for logins (its system-auth on redhat based distros)

session    required     pam_tty_audit.so enable=*

To find out what was done, you can use.

ausearch -ts <some_timestamp> -m tty -i

This produces an output like this:

 type=TTY msg=audit(11/30/2011 15:38:39.178:12763684) : tty pid=32377 uid=root
 auid=matthew major=136 minor=2 comm=bash data=<up>,<ret>

The only downside to this is is can be a little bit difficult to read, but it is much better than most proposed solutions since in theory it could be used to record an entire session, warts n all.

Edit: Oh and you can use aureport to generate a list that can be more helpful.

# aureport --tty
...
12. 11/30/2011 15:50:54 12764042 501 ? 4294967295 bash "d",<^D>
13. 11/30/2011 15:52:30 12764112 501 ? 4294967295 bash "aureport --ty",<ret>
14. 11/30/2011 15:52:31 12764114 501 ? 4294967295 bash <up>,<left>,<left>,"t",<ret>

Check more discussion of this question.

Assuming hardware failure is not a factor, and the requirement of being able to update periodically, is it possible to never shutdown Linux?

I typically do a full reboot after updates, especially kernel updates, but is there a way to keep my machine on and still do these? People always hear about incredible up-time, but how is that really possible if you must reboot after major updates.

Maybe a different run level? But then how would the kernel update kick in?

Server/Box “uptime” is an illusion. Unless your objective is to have incredible uptime in order to prove some kind of point then I wouldn’t focus on it.

What matters is service availability. If you need a service to be available all the time then it might be useful to improve individual system uptime or it may well be simpler and more cost effective to create a cluster, for example, than to try and take the availability of a commodity server from 99% to 99.999%

Check more discussion of this question.

I know the linux command

echo "- - -" > /sys/class/scsi_host/host0/scan

is used to rescan scsi host. But what does “- – -” mean in the command?

The three values stand for channel, SCSI target ID, and LUN. The dashes act as wildcards meaning “rescan everything”

A quick google search turns up this RHEL doc (and dozens of other answers)

This is the same command described in Section 7, “Adding a Storage Device or Path” to add a storage device or path. In this case, however, the channel number, SCSI target ID, and LUN values are replaced by wildcards. Any combination of identifiers and wildcards is allowed, allowing you to make the command as specific or broad as needed. This procedure will add LUNs, but not remove them.

Check more discussion of this question.