Archive for the ‘Linux’ tag
CentOS 6.0 available!
As of yesterday, the good people at www.centos.org have published their clone of Red Hat 6.0, CentOS 6.0.
I’ve downloaded it using the bittorrent within an hour or so, so if you have a fast connection, that is the way to go
See their site for detailed information.
Scientific Linux 6.0 available for download
If you got to this page, chances are you have heard of Red Hat Enterprise Linux (RHEL), which is a very nice and stable Linux based OS distribution.
For a number of years, completely legal clones of RHEL have been created by the good people of CentOS (www.centos.org) and Scientific Linux (www.scientificlinux.org).
Scientific Linux (SL) has now created their version 6.0, which is based on (in practice is a somewhat enhanced close of-) RHEL 6.
You can download it from their site.
To “share the load” I’ve created torrent seeds for the most popular stuff; the i386 and the x86_64 ISO files.
Download the torrents below and open them in your favortie torrent downloader.
Have fun!
http://mail.vive-id.nl/~vincent/torrents/scientific-linux-6_0_i386-full-iso.torrent
http://mail.vive-id.nl/~vincent/torrents/scientific-linux-6_0_x86_64-full-iso.torrent
Permissions for .ssh autorized_keys file & directory
It’s one of those thing you don’t do often enough to remember how to, so when I ran into it again this morning, I decided to write it down
To get asymmetric (public/private) key authentication working with sshd, you need to be the only one who has access to your ~/.ssh directory, so you need to do a
chmod 700 ~/.ssh
The ~/.ssh/authorized_keys file may be world readable ( “chmod 644 ~/.ssh/authorized_keys”).
What does the “pipe” value mean in the output of “ping”?
When you use the ping command, sometimes you get a “pipe” value at the end of the rtt statistics. So what does this mean? I had to dive into the actual ping source code to find out. Here it is
The “pipe” number is the maximum number of echo request packets that have been under way at one time, without having been answered by an echo reply packet (but did get answered in the end).
Normally, ping will send a so called echo request, wait for a second an then send the next echo request.
When it has sent the second echo request before the first has been answered, the pipe number is raised Read the rest of this entry »
Vbackup renamed to Yabs. New version released.
First, I’ve renamed my Vbackup project to Yabs.
Vbackup proved to be an already existing project for a backup solution, so I decided to look for a more unique name.
The new name didn’t turn up in Google, and that’s enough for me
From now on, vbackup will be known as yabs, which is an acronym for “Yet Another Backup Script”. How original
Together with the renaming, I’ve released a new version, numbered as 1.1.0. Here are the most important updates:
# Revision history
#
# version 1.1.0 -
# – Renamed the program from vbackup to yabs. Vbackup was an existing project by someone else.
# – Changed the logic for logging erros. You can now use a log file, syslog, both or none.
# – Added some extra checks for consistency in user defined variables.
# – Added the backup destination to the exclution list. No more backing up the backups.
# – Added the -xdev switch logic to “find”. Gives the possibility to exclude other file systems or not.
# I’ve set this to YES by default, so things like /proc, /sys, /dev, etc will not be included in the backups.
You can download the new version here: http://www.xs4all.nl/~vincentv/yabs-1.1.0.tgz
Again, make sure to save this as a .tgz file. Some browsers get this wrong.
vbackup – script to backup RHEL/CentOS/Fedora systems released
A long time ago I started writing a Bash script to create backups for my systems.
Over time this script has developed into something I and some collegues and friends find useful, so I decided to publish it and see if more people are interrested in using it. If so, I’ll try and maintain it.
The program is released under the GNU GPL v3.
My backup regime consists of making a full backup once a week and then a daily differential backup since the time of the full backup. This script obviously concentrates on that. If you need incremental backups, adapt the script to your needs.
The script was written for CentOS 4 and 5 systems, and most likely will run without a hitch on all Red Hat derivates like Fedora.
The main features of this script are:
- Option to exclude files and directories from the backup by specifying exclusions as regular expressions. Sound difficult? Isn’t! See the included example. Google “perlretut” for excellent documentation on learning regular expressions.
- Options to set the location of the backup files, temporary files, etc.
- Options to have backup files and/or log files stored uncompressed or compressed with gzip or bzip2.
- Option to have sha1 checksums generated and stored to check file integrity afterwards.
- Options to have custom commands executed right before and after the backup. You could use these to rsync files to an off site location, mail backup logs, whatever. See the script for some simple examples.
All options are documented withtin the script file. Open it, browse through them and change them before using the script!
Let me know when you find serious errors. Suggestions are always welcome. How to contact me is on the end of the README file. I may not get back to every single email, but I’ll try
You may download the script here: http://www.xs4all.nl/~vincentv/vbackup-1.0.0.tgz
Make sure you save the script as a .tgz file. Some browsers get the extension wrong.
Happy backupping
First experiences with the Intel D945GCLF board under Linux and Windows XP
I’ve worked with my new Intel D945GCLF mini-ITX board for a while now, here are some observations:
- When installing the board in any chassis, make sure that your power supply has a 4-pin ATX “P4″ connector. The board needs it and won’t run without it!
- The CPU used on the board, the Intel Atom 230, doesn’t support SpeedStep technology, and will always run at full speed. This is a no-no if you’re trying to build an as-low-as possible-power-consuming device.
- Because of the constant full speed, the CPU gets very hot when simply disconnecting the fan. It didn’t crash within 15 minutes, but I’m sure it will shorten the CPU lifetime.
- The CPU fan always runs at full speed and is quite noisy. Without any modifications, I would not use this board in very quiet environments. Maybe a Zalman FanMate will help here.
- The cooling fins attached to the CPU are quite high. So high that makes the standard cooler to big for a 1U high chassis.
- There is a problem installing CentOS 5.2 or Fedora 9 from the standard ISO’s. See this post.
- When trying to install Windows XP, make sure you’re installing it with SP2 or SP3 slipstreamed in. The install will fail with the original Windows XP or with SP1 (you’ll get a blue screen complaining about pci.sys).
All in all, I like the board, but wouldn’t use it for anything else than (busy) office or home environment desktop applications. But then, that’s exactly what Intel says the board is for
Happy building!
Installing CentOS / RHEL / Fedora on an Intel D945GCLF mini-ITX board
I recently bought a new Intel D945GCLF mini-ITX board (http://www.intel.com/Products/Desktop/Motherboards/D945GCLF/D945GCLF-overview.htm) and had some problems installing Linux on it.
The problem I encountered was that the installation would cause a kernel panic (“Oops…”) early on in the process.
I’ve tested this with CentOS 5.2, and Fedora 9 and both gave the same results.
The problem seems to be the driver for the on board LAN interface. This is a Realtek 8102EL fast ethernet with PCI Express interface chip, but all the installations try to load the Realtek r8169 driver and that’s where it fails.
The solution is to (these instructions work for CentOS / RHEL, for Fedora 9 see below):
- Download the correct driver (the r8101 is correct, this works for the r8102!) from the Intel web site (which is here at the time of this post: Read the rest of this entry »
Capturing Linux kernel panic info
In some situations, Linux kernel panic info can be hard to capture for later analysis.
Normally, the only thing you’ll get is a lot of info on the console screen and if you’re very lucky you may find some info in a logfile.
To capture the console-based info, you don’t have a lot of options. The one I use is to have the console “copied” to a serial port. Once that’s in place, you can capture the info that’s being dumped on another machine via the serial interface.
Even better, when you’re using a virtualized environment like VMware, you can instruct VMware to dump anything the guest OS outputs through the serial interface to a text file on your host. That way, you’ll have the kernel panic info readily available for later analysis.
First of all, you’ll have to add an extra kernel parameter, so that Linux knows you want to use a serial port as a console device. Luckily, this is not so hard.
The instructions below work for RHEL, CentOS, FC and Read the rest of this entry »
Fast backup and restore of MySQL databases
I use MySQL version 5 for a number of databases and have been looking for a fast way to back them up and restore them.
What I wanted was the fastest possible way to create a copy of my databases and a relatively easy way to restore them.
I soon found mysqlhotcopy, but when copying all databases at once, it locks all tables during the copy operation. To circumvent this, I wrote a small Bash script that will execute mysqlhotcopy for every database separately, so the others remain accessible during the backup.
To speed things up, I tell mysqlhotcopy not to include indices, as I can easily recreate those when I need to restore a database.
The script runs from cron on a daily basis, is fairly simple and looks like this: Read the rest of this entry »