Let’s assume that you are using github for version control of some projects you want to make public. But you also want to push your repository to a second repository, maybe a private one you one on a VPS or something similar – just for backup reasons or in case you want to leave github someday.
This is easily achievable by just adding another remote, pushing to it and creating an alias for convenience. Let’s assume we want to name our secondary origin “backup”:
First create the folder and do an initial pull from github of your own repository:
dan@bart ~ $ mkdir XML-to-text-Tomboy
dan@bart ~ $ cd XML-to-text-Tomboy
dan@bart ~ $ git clone git@github.com:danakim/XML-to-text-Tomboy.git ./
Now let’s add the second remote origin and do an initial push to it:
dan@bart ~/XML-to-text-Tomboy $ git remote add backup user@server:/path/to/git/XML-to-text-Tomboy.git
dan@bart ~/XML-to-text-Tomboy $ git push backup master:master
And finally add an “all” alias for both remotes to make sure it’s easy to push to both of them every time:
dan@bart ~/XML-to-text-Tomboy vi .git/config
Add the following entry:
[remote "all"]
url = git@github.com:danakim/XML-to-text-Tomboy.git
url = user@server:/path/to/git/XML-to-text-Tomboy.git
Now every time you commit you can just run
dan@bart ~/XML-to-text-Tomboy $ git push all
Hope some of you have found this useful!
I use KVM (Kernel Virtual Machine) to run tens of virtual machines for a development environment. What makes life easier when it comes to managing all these machines is the “virsh” tool. It’s a script that runs on the host and lets you easily control your VMs: start, shutdown, destroy, change configurations etc.
But recently one of the VMs I was running was not responding to any of the commands I was sending through virsh. I was trying to run “virsh shutdown ” but the guest kept on running. The fix to this problem was quite easy: the ACPI deamon needs to be running on the guest / VM to be able to receive commands from virsh. For some reason that particular guest didn’t have ACPId running or installed. So just use your package manager of choice and install and start ACPI on the guest and everything should be fine!
One of the less known functionalities implemented in the Linux kernel is the Magic SysRq key. Initially implemented as a debugging feature for kernel development it has also made its way into system administration use and the /proc filesystem.
Basically the Magic SysRq keys are low level commands that can be sent to the kernel regardless of a system’s state. That being said it can be most useful in extreme cases where the system is not responding to do a reboot, unmount partitions or sync the partitions (flush their write buffer to disk).
Before being able to actually use this, you have to enable the SysRq keys:
echo “1″ > /proc/sys/kernel/sysrq
All these commands can be sent to the kernel using the combination:
or by piping the key to the /proc filesystem:
echo [key] > /proc/sysrq-trigger
The SysRQ key on the keyboard can usually be found on the same key as “PrintScreen”.
A full list of the commands that can be sent can be found on Wikipedia.
Now you ask yourself, when would I use this? Let’s take the most common example: a server that has become completely unresponsive and the only solution would be to reboot it. But that server hosts a database with precious information and you do not know if all the information kept in memory by the database has been written to disk or if the sudden reboot would trigger errors and inconsistencies on the filesystem. The Magic SysRQ keys would come in handy now:
- gracefully terminate all running processes except init (PID1):
or
echo “e” > /proc/sysrq-trigger
- kill all the stubborn processes:
or
echo “k” > /proc/sysrq-trigger
- sync all mounted filesystems – meaning flush all the memory buffers to disk:
or
echo “s” > /proc/sysrq-trigger
- re-mount all partitions as read-only:
or
echo “u” > /proc/sysrq-trigger
- finally tell the box to immediately reboot:
or
echo “b” > /proc/sysrq-trigger
The case above is the most common one, but there are other times on the SysRq keys might come in handy. Let’s say you have accidentally deleted something from an ext2/3/4 partition. We know that on those filesystems the data isn’t immediately removed from the drive, but marked as deleted and will be overwritten the next time a process tries to write somewhere on the disk. Before you can use tools to un-delete – we will cover that in the next episode – we can tell the kernel to force re-mount all partitions as read-only, including the / partition:
or
echo “u” > /proc/sysrq-trigger
Now we can be sure that no process will overwrite our precious data and use some tool to recover the metadata.
For a while now I have been using at home a media center based on Ubuntu and Boxee, a setup which I find amazing in so many ways. Recently looking to customize things a bit more I have been thinking of changing Ubuntu’s default splash screen with one that show the Boxee logo.
Because Ubuntu has moved to using Plymouth for a while now, the task involved creating a Plymouth theme. Not wanting to write one from scratch I have used the default Ubuntu one (ubuntu-logo theme) and modified the script and the png files.
The result of this you can find in the tarball. To install it you have to:
- download the tarball: http://www.hostatic.ro/uploads/boxee_plymouth_theme.tgz
- untar boxee.tgx in /lib/plymouth/themes. You should get a folder named “boxee” under “themes”
- run: sudo update-alternatives –install /lib/plymouth/themes/default.plymouth default.plymouth /lib/plymouth/themes/boxee/boxee.plymouth 100
- run: sudo update-alternatives –config default.plymouth and select from the list the number corresponding to the theme named “boxee”
- run: sudo update-initramfs -u
That’s it! Reboot and enjoy!
Sometimes Apache 2′s logs can get really polluted by entries which you don’t care about and might skew your statistics. For example you wouldn’t want your own IP address in the logs because you don’t want that counted in the statistic. Although most web analyzers have filters to exclude such things, you can do this directly in Apache by not logging these. To do this you first need to set and environment variable that matches what you don’t want to log – this can use regular expressions and the matching is done on HTTP header fields like Remote_Addr or Request_URI.
Let’s say you want to exclude all internal IPs in your company from your website’s logs. You need to add this to your httpd.conf or .conf, depending on how you have your web server set up:
SetEnvIf Remote_Addr “10\.*\.*\.*” nologging
This just created a new variable in Apache’s environment called “nologging”. Now we will add this to the log directive in the same config file:
CustomLog log/access.log combined env =! nologging
Now Apache will log everything except what is matched with the rule above. If you want to add more things to the list of non-logging, we can just continue adding rules to that variable. Let’s we decided not to add the favicon.ico requests to the log:
SetEnvIf Request_URI “^/favicon\.ico$” nologging
That’s it, no more pesky favicon requests in the logs! As you can see, the rules are pretty powerful and there are many uses for this!
Also, don’t forget that you need the “log_config” and the “setenvif” module loaded in Apache! As usual you can check this using httpd -M or apache2 -M on the command line.
For more details: http://httpd.apache.org/docs/2.2/mod/mod_log_config.html
Sometimes you may need to find out the umask a process will use to write to the filesystem – in a Linux environment – but you can not afford to shut down the process – let’s say it is in production at the moment.
Doing this isn’t as trivial as you would expect, as the /proc filesystem doesn’t offer any information about this. The easiest way I have found is to attach gdb to the running process and calling umask to get the information. We will use the SSH daemon as example:
- first find the PID (process ID) of the daemon:
ps -ef | grep sshd
root 1083 1 0 21:24 ? 00:00:00 /usr/sbin/sshd -D
- install gdb using your favorite package manager (or compile it) if you don’t have it and attach gdb to the running process:
gdp –pid=1083
- you will be presented with the debugger’s shell in which you can call system functions. we need to call the umask function to get what we need:
(gdb) call umask(0)
$1 = 18
- This sets the umask of the running process to 0 but also returns at the prompt the previous value of the umask. The returned value – 18 in our case – is the umask represented in the decimal system. Because in userspace we use the octal system to represent umasks you need to convert it to octal. So fire up your favorite calculator and convert it from decimal to octal. 18 translates to 22 in octal, meaning our running process has a umask of 022. That means that the process will write files with 644 as permissions on the filesystem.
- Now that you found out what the umask was, set it back:
(gdb) call umask(18)
$2 = 0
- type “quit” to detach gdb from the process
One of the most annoying things that can happen when using BIND9 with a lot of slave servers is, mistakingly, setting the serial number for a zone file in the future.
Let’s assume that your are using the current date plus a 2-digit number as your serial number. This is a pretty standard thing that lots of admins use:
serial 2011022700;
Then you or someone else not paying attention when updating the zone file set the serial to 201102701. This is missing a “2″ digit, thus setting the serial higher – or in the future in our case. When reloading bind this broken serial will be pushed to all the slaves and all further updates to your zone file will have to use the broken serial number and just increment it instead of using your current date. This is because if you just fix the serial number on the master to the current date, the slaves won’t be notified of the update because the serial on the master will be a lower number. It will work but it will break the consistency and standards that you worked so hard in implementing in your systems.
So to fix it you have two choices:
1) Fix the serial number on the master and then write a bash / perl / python script to ssh into all the slaves, delete the broken zone file from all of them and restart bind. This will force the slaves into re-requesting the zone file from the master, zone file that will have the corrected serial. This method will work but it involves more work and might go wrong if you are not careful.
2) Use a functionality that is available in BIND9 and documented in their manual. It involves incrementing the serial number on the master with the highest value possible. This will effectively “reset” the serial allowing you to start over from whatever value you want. The highest value possible is: 2^31-1 = 2147483647
The steps are:
- Add the number 2147483647 to your broken serial number and write it in your zone file on the master server. In our case: 2147483647 + 2011022701 = 4158506348
- Reload your zone file: rndc reload
- This time your zone file will be pushed again on all your slaves because it is the highest available value you can increment it with
- Reset the serial number to the value you want, the correct value – the current date: 2011022700
- Reload the zone file on the master server again: rndc reload
- This time the update will work and the master and all the slaves will have the correct serial number
Hope it helps!
For reference this is the manual page:
http://www.bind9.net/manual/bind/9.3.2/Bv9ARM.ch08.html