The majority of the file management I do at work is through the terminal, however sometimes it is necessary to view/work with files through Nautilus. I’ve added the following command to my ~/.bashrc, causing openme to launch the current working directory in Nautilus.
alias openme='nautilus --browser . 2> /dev/null'
The shell provides multiple shortcuts via the usage of the exclamation point when trying to execute recently performed commands. Err the Blog’s Bash Cheat Sheet provides the following tips and more.
If you need to run the most recently executed command again
!!
If the last command run requires super user privileges
sudo !!
Run the most recently executed command beginning with foo
!foo
Retrieve the last ‘word’ of the most recently executed command. In the example below, !$ would have the value my_database.
mysqldump -u root -p my_database
!$ # Will contain the value 'my_database'
Similar to the example above, this shortcut contains all ‘words’ except the first in the most recently run command. Using the same mysqldump command above, !* would have the value -u root -p my_database.
mysqldump -u root -p my_database
!* # Will contain the value '-u root -p my_database'
Note that the above commands can have :p appended, printing the commands or ‘words’ that the exclamation point replacement would use instead of running them as part of a new command in shell. The example below would print the most recently executed command beginning with foo
!foo:p
Using CentOS 5 on my VPS, I recently found that newly created cPanel accounts running cPanel/WHM 11.24 RELEASE seemed to have some trouble properly setting permissions to allow the jailshell cPanel users to access/manage their crontab.
Setting up cron jobs via cPanel’s web interface itself worked just fine, but when trying to manage a jailshell users crontab via shell, the permissions were not set up properly to allow for this.
As d4ly you can see I don’t have permission to view/edit the crontab for d4ly
d4ly@d4ly.com [~]# crontab -e
cron/d4ly: Permission denied
So as root I did the following
root@server [~]# chmod 4775 /usr/bin/crontab
root@server [~]# cd /var/spool/cron
root@server [/var/spool/cron]# chmod 0755 .
root@server [/var/spool/cron]# chown d4ly.d4ly. d4ly
root@server [/var/spool/cron]# ls -l
total 24
drwxr-xr-x 2 root root 4096 Feb 4 17:03 ./
drwxr-xr-x 13 root root 4096 Sep 9 09:51 ../
-rw------- 1 d4ly d4ly 37 Feb 4 14:54 d4ly
-rw------- 1 root root 1555 Jan 19 20:52 mailman
-rw------- 1 root root 32 Jan 11 16:42 munin
-rw------- 1 root root 485 Jan 26 13:17 root
Then I tested things out once more as d4ly
d4ly@d4ly.com [~]# crontab -e
MAILTO="d4ly"
0 0 * * * ping d4ly.com # This cron is for testing jailshell crontab editing
The source code for D4core is maintained in and SVN repository. I have found it helpful to create a .cleanup and .commit Bash script in the root directory of our framework’s repository.
.cleanup has the task of removing cached files, temporary files, and log files which are no longer relevant to the current development cycle. It also use it currently to reformat our XML configuration file with pretty whitespace using xmllint.
#!/bin/bash
echo "Cleaning D4core..."
rm -f D4core/Content/Cache/Smarty/*
rm -f D4core/Content/Compile/Smarty/*
rm -f D4core/Content/Cache/Minify/*
rm -f D4core/Config/Backup_*
rm -f D4core/Log/Error/*
rm -f D4core/Log/Logs/*
xmllint -format D4core/Config/Config.xml -output D4core/Config/Config.xml
echo 'Running `svn status`...'
svn status
echo "Cleaning D4core completed."
.commit (which calls .cleanup initially) is responsible for managing the commit process. This file is run only after all project files have been added/removed/moved within the working copy and we are ready to commit to SVN.
#!/bin/bash
./.cleanup
svn commit
echo "D4core SVN commit complete."
By running ./.cleanup before committing code to the repository it becomes a lot easier to ensure the status and location of all files within the working copy are correct. These simply scripts easily save me 5 minutes a day in shell.
This displays the number of open connections to port 80 on a server, dumping the ip address/connection count pairs in ascending order.
netstat -anlp | grep :80 | awk '{print $5}' | awk -F: '{print $1}' | sort | uniq -c | sort -n
This can be useful in combination with grep1 searches performed on
httpd fullstatus
to determine if a DOS attack is being performed on a server.
When recompiling SVN 1.5.5 from source, making sure to include the swig-py bindings to allow Trac to read from local SVN repositories, I used the following ./configure command
./configure --prefix=/usr/local/svn-1.5.5/ --with-apr=/usr/local/apr/bin --with-apr-util=/usr/local/apr/bin --with-neon=/usr/bin --with-apxs=/usr/local/apache/bin/apxs
When trying to view my repository I was presented with the following error in my trac.log file
SubversionException: ("Can't set position pointer in file '/var/svn/db/revs/135': Invalid argument", 22)
After some research1 I found the most common cause of this error is that Subversion was compiled against a different version of apr and apr-util than apache was. I found apache compiled with cPanel’s EA3 uses
/usr/local/apache/bin
as it’s path for apr and apr-util. Changing the flags to reflect this when compiling Subversion I was left with
./configure --prefix=/usr/local/svn-1.5.5 --with-apr=/usr/local/apache/bin --with-apr-util=/usr/local/apache/bin --with-neon=/usr/bin --with-apxs=/usr/local/apache/bin/apxs
make swig-py
make install
make install-swig-py
cd /usr/local/svn-1.5.5/lib/svn-python/
cp -r libsvn/* /usr/lib/python2.4/site-packages/libsvn
cp -r svn/* /usr/lib/python2.4/site-packages/svn
service httpd restart
I also ran the following out of habit after recompiling SVN before restarting httpd.
trac-admin TRAC_ENV_PATH resync
Below is one way to quickly and simply clear all /.svn directories from a SVN working copy; useful in a variety of situations.
find . -type d -name .svn -exec rm -rf '{}' ; -print 2> /dev/null
Restarting httpd while trying to alleviate high load on one of the servers I manage, I was recently presented with the following error
(28)No space left on device: Couldn't create accept lock
After some research I found running the following command1
ipcs -s
showed there were a bunch of semaphores hanging around even though apache had been stopped normally via
service httpd restart
Similar to the code snippet mentioned by Major over at RackerHacker, the following command clears out those semaphores, letting httpd start up without a problem
ipcs -s | grep nobody | perl -e 'while (<STDIN>) { @a=split(/\s+/); print `ipcrm sem $a[1]`}'
