bofh468
Is this you? Claim Profile »
5 years ago
in Create a hard link in UNIX | UNIX | Tech-Recipes on Tech-Recipes
Probably a better way of describing the difference between hard and soft links:
The UNIX file system stores files in inodes. The filesystem table contains a list of filenames, and the pointer to the inode in which that file exists.
A hard link creates a second entry in the filesystem table pointing to the same inode of the file. This can be illustrated with the ls command very easily:
What did I do above? Here's a play-by-play:
1: create a file (/this)
2: hardlink the file (/this) to another file (/root/that)
3: ask to see the inodes that the files exist in
4: note that the inode numbers are identical - 18
5: delete the original file
6: show me the inode of the other file again
7: it's still the same.
In the above example, Inode 18 is occupied only once, and is referenced by two different path/filenames. Removing the first file doesn't in any way affect the second. The actual inode is still in use by the second reference. As soon as you remove all references, the inode is considered unused and can have new data written to it.
One caveat - hard links cannot span mount points. My own home directory is mounted from another disk, for example, so I cannot hardlink from /this to /home/bofh/that. The other caveat is that you cannot hard link directories.
Soft links are really pointers to a pointer. ls -i on both files will still show they are pointing at the same inode... but if you remove the original file, then the inode is actually completely dereferenced. The plus-side is that soft links can span mount points and you can soft link directories. The downside is that if you remove the original then the link is broken.
The UNIX file system stores files in inodes. The filesystem table contains a list of filenames, and the pointer to the inode in which that file exists.
A hard link creates a second entry in the filesystem table pointing to the same inode of the file. This can be illustrated with the ls command very easily:
1: # touch /this
2: # ln /this /root/that
3: # ls -i /this /root/that
4: 18 /root/that 18 /this
5: # rm -f /this
6: # ls -i /root/that
7: 18 /root/that
What did I do above? Here's a play-by-play:
1: create a file (/this)
2: hardlink the file (/this) to another file (/root/that)
3: ask to see the inodes that the files exist in
4: note that the inode numbers are identical - 18
5: delete the original file
6: show me the inode of the other file again
7: it's still the same.
In the above example, Inode 18 is occupied only once, and is referenced by two different path/filenames. Removing the first file doesn't in any way affect the second. The actual inode is still in use by the second reference. As soon as you remove all references, the inode is considered unused and can have new data written to it.
One caveat - hard links cannot span mount points. My own home directory is mounted from another disk, for example, so I cannot hardlink from /this to /home/bofh/that. The other caveat is that you cannot hard link directories.
Soft links are really pointers to a pointer. ls -i on both files will still show they are pointing at the same inode... but if you remove the original file, then the inode is actually completely dereferenced. The plus-side is that soft links can span mount points and you can soft link directories. The downside is that if you remove the original then the link is broken.
5 years ago
in Extract a gzip compressed tar archive in Linux | Linux | Tech-Recipes on Tech-Recipes
Another useful switch is -j for handling bzip2 compression. To do the same as above for a bzip-compressed tarball:
tar xjf filename.tar.bz2
5 years ago
in Tar and compress a file in one step on Tech-Recipes
Although this probably belongs under the OpenSSH section, this is a really neat trick for snapping a tarball of a machine with limited diskspace, and storing the output on your workstation (or machine that your SSH'ing from).
You must already have the hostkey from the remote machine (i.e., logged in at least once) otherwise this will fail. SSH allows you to connect to a remote machine and pass a commandline rather than firing up an interactive shell. The output is then dumped to your local console for further processing.
Before you scratch your head, think of this. You have a machine that has virtually no space left (or at least, not enough to make that tarball). qmchenry's post shows you how to get tar to spool the archive to stdout:
What if you can capture that to your own workstation, which probably has ample space. Picture this:
You've just had the remote machine produce a tarball, run it through gzip, and dump the results to stdout. You just captured that at your own workstation, and saved the results.
You must already have the hostkey from the remote machine (i.e., logged in at least once) otherwise this will fail. SSH allows you to connect to a remote machine and pass a commandline rather than firing up an interactive shell. The output is then dumped to your local console for further processing.
Before you scratch your head, think of this. You have a machine that has virtually no space left (or at least, not enough to make that tarball). qmchenry's post shows you how to get tar to spool the archive to stdout:
tar -cf - target
What if you can capture that to your own workstation, which probably has ample space. Picture this:
ssh user@remotemachine "cd /path;tar -cf - target | gzip -c" > /path/target.tgz
You've just had the remote machine produce a tarball, run it through gzip, and dump the results to stdout. You just captured that at your own workstation, and saved the results.
5 years ago
in Change the MySQL root user password | MySQL | Tech-Recipes on Tech-Recipes
Whether or not passing the password on the command line or in a shell script is a security risk is debatable. First, let me show you something:
$ ps -efwww | grep mysql
bofh 4599 4571 0 20:24 pts/4 00:00:00 mysql -h db1 -u root -px xxxxxx
The password field that you see in there is not altered by me in any way. That's what the output of ps reports. The MySQL tools do a wonderful job in not showing the passwords in the process list. Not all tools are this considerate.
That aside, you must remember that command will be saved in .bash_history - which is normally only readable by the user (bofh in this case) and root. Storing such a password in a script will also possibly allow other system users to view the password if they can read the script. Of course, root can always read files.
I have a general policy at work on machines that I manage - Secure any scripts that may contain such passwords. Chown them to 700. If anybody can compromise the box to read those files, I have far more to worry about than the MySQL root password (which is super easy to override if you can restart mysqld).
Systems administration is not just about locking up the box so that it's barely useable. It's about maintaining a careful balance between security and useability for users.
I suppose a slightly better way to balance the situation might be to have a dedicated MySQL DB server that has no local user access, and the root mysql account is retricted to local logins. That's really only feasible if you have equipment to spare.
$ ps -efwww | grep mysql
bofh 4599 4571 0 20:24 pts/4 00:00:00 mysql -h db1 -u root -px xxxxxx
The password field that you see in there is not altered by me in any way. That's what the output of ps reports. The MySQL tools do a wonderful job in not showing the passwords in the process list. Not all tools are this considerate.
That aside, you must remember that command will be saved in .bash_history - which is normally only readable by the user (bofh in this case) and root. Storing such a password in a script will also possibly allow other system users to view the password if they can read the script. Of course, root can always read files.
I have a general policy at work on machines that I manage - Secure any scripts that may contain such passwords. Chown them to 700. If anybody can compromise the box to read those files, I have far more to worry about than the MySQL root password (which is super easy to override if you can restart mysqld).
Systems administration is not just about locking up the box so that it's barely useable. It's about maintaining a careful balance between security and useability for users.
I suppose a slightly better way to balance the situation might be to have a dedicated MySQL DB server that has no local user access, and the root mysql account is retricted to local logins. That's really only feasible if you have equipment to spare.
5 years ago
in Restart Apache without closing open connections | Apache web server | Tech-Recipes on Tech-Recipes
Failing to find apachectl, one could just find the PID of the parent httpd process and send a -USR1 signal to it.
For example:
a -USR1 signal will cause any new children to run with a new configuration, but leave the current children running as-is. A -HUP signal will kill off all current children and cause new requests to be serviced under the new configuration.
Of course, one could be a little more sophisticated:
That said, apachectl is a lot cleaner.
For example:
$ ps -ef | grep httpd
root 17723 1 0 Sep23 ? 00:00:01 /usr/sbin/httpd -DHAVE_ACCESS -D
apache 3666 17723 0 Nov09 ? 00:00:00 /usr/sbin/httpd -DHAVE_ACCESS -D
apache 3667 17723 0 Nov09 ? 00:00:00 /usr/sbin/httpd -DHAVE_ACCESS -D
apache 3668 17723 0 Nov09 ? 00:00:00 /usr/sbin/httpd -DHAVE_ACCESS -D
apache 3669 17723 0 Nov09 ? 00:00:00 /usr/sbin/httpd -DHAVE_ACCESS -D
apache 3670 17723 0 Nov09 ? 00:00:00 /usr/sbin/httpd -DHAVE_ACCESS -D
apache 3671 17723 0 Nov09 ? 00:00:00 /usr/sbin/httpd -DHAVE_ACCESS -D
apache 3672 17723 0 Nov09 ? 00:00:00 /usr/sbin/httpd -DHAVE_ACCESS -D
apache 3673 17723 0 Nov09 ? 00:00:00 /usr/sbin/httpd -DHAVE_ACCESS -D
$ kill -USR1 17723
a -USR1 signal will cause any new children to run with a new configuration, but leave the current children running as-is. A -HUP signal will kill off all current children and cause new requests to be serviced under the new configuration.
Of course, one could be a little more sophisticated:
$ ps -ef | grep httpd | grep root | awk '{print $2}' | xargs kill -HUP
That said, apachectl is a lot cleaner.
5 years ago
in Remove ^M characters at end of lines in vi | UNIX | Tech-Recipes on Tech-Recipes
Another way to do this is with the dos2unix utility. You can also use unix2dos to add in the extra ^M (carriage-return) characters to a text file so it's readable under DOS.
5 years ago
in MySQL - Daily database dumps, all nicely sorted. | MySQL | Tech-Recipes on Tech-Recipes
I know that replying to oneself is bad karma... but I noticed a typo above. The backup files will be located under /home/backups/mysql/dbname-YYYY-MM-DD.tar.gz
5 years ago
in Make Linux ignore a ping | Linux security | Tech-Recipes on Tech-Recipes
Even better:
don't ignore ICMP echos:
do ignore ICMP echos:
sysctl -a will give you a nice list of values that you can tweak.
If you're running a Redhat-based system, you can plop the desired values in /etc/sysctl.conf.
don't ignore ICMP echos:
sysctl -w net.ipv4.icmp_echo_ignore_all=0do ignore ICMP echos:
sysctl -w net.ipv4.icmp_echo_ignore_all=1sysctl -a will give you a nice list of values that you can tweak.
If you're running a Redhat-based system, you can plop the desired values in /etc/sysctl.conf.