Your Linux Guy .com

There are lots of ways to design and run your dhcp server and environment.  Over the years, I’ve kinda’ fallen in-and-out of love with DHCP clustering;  I’ve just come to the conclusion that it is more trouble than it’s worth.  I stumbled on this “peering” or “fail-over” method of running dhcpd when I was preparing for a Novell Practicum (believe it or not) and have recommended doing it this way from then on.  So on with the show then;  here’s my dhcpd failover cheat sheet.

Note that although the following examples were all done on a Suse machine, they should work with some alterations on most Linux Distros, basically wherever the standard dhcpd package is installed and running.

The logic behind this is this:  You have two Linux servers.  Both have the dhcpd software installed.  You want to run dhcpd on both of them simultaneously, but you understand that without some special configuration modification, this will cause havoc on your network.

In order to accomplish that, you basically move the traditional dhcpd.conf to a secondary file dhcpd.conf.master, and “include” that file from a “new” dhcpd.conf that will include the failover instructions.  This is because the failover stuff must come first in sequence, and is unique to each of the two machines.  And the old, standard stuff is the same on both machines and can come second.

Also, the dhcpd.conf.master file must be copied into the chroot environment in order to work. You can do this manually, or on Suse, set the DHCPD_CONF_INCLUDE_FILES="/etc/dhcpd.conf.master" variable in /etc/sysconfig/dhcpd.  Don’t forget to run SuSEconfig when done making changes, to have the files copied over for you.

Of course, you could just cram all this stuff into one file, but with the separate files it is easier to maintain the static content (and copy it across as needed).  But I don’t like to do this.  I like to keep them separate for ease of copying, tracking, etc.

Anyway, here are examples of the conf files:

———————————————
Primary server dhcp.conf:
———————————————
failover peer "yourlinuxguy"
{
primary;
address 192.168.1.5;
port 847;
peer address 192.168.1.6;
peer port 647;
max-response-delay 180;
mclt 1800;
split 128;
load balance max seconds 3;
}
# Now include the master config file from both machines
# Don't forget to copy it into the chroot section!
include "/etc/dhcpd.conf.master";
———————————————

Secondary server dhcpd.conf:
———————————————
failover peer "yourlinuxguy"
{
secondary;
address 192.168.1.6;
port 647;
peer address 192.168.1.5;
peer port 847;
max-response-delay 180;
load balance max seconds 3;
}
# Now include the master config file from both machines
# Don't forget to copy it into the chroot section!
include "/etc/dhcpd.conf.master";
———————————————

The dhcpd.conf.master on both hosts:
———————————————
ddns-update-style none;
default-lease-time 86400;
max-lease-time 86400;
option domain-name "yourlinuxguy.com";
option domain-name-servers 192.168.1.3, 192.168.1.4;
option routers 192.168.1.1;
subnet 192.168.1.0 netmask 255.255.255.0
{
pool
{
failover peer "yourlinuxguy";
deny dynamic bootp clients;
range 192.168.1.50 192.168.1.100;
}
}
———————————————

And that’s it!  Now, you’ve got dhcp running on both servers, splitting hte work, sharing the running leases database, so that if one fails, the other takes over.  When the failed one comes back, they re-share all the changed information and pick up where they left off.  Big props to the man pages, and please see them for further explanation of any of the options in my examples above.  This is just a cheat sheet folks!

Brilliant!

I like the agedu utility.  I recently found it while searching the ‘net, and I want to thank all involved with it (see the page for credits and info).

This neat utility helps you get a general understanding of two main things: 1.) How much space you’ve consumed on the filesystem, and 2.) roughly how old it is… in a single, graphical (optionally) representation.  Of course, at the time of this writing, it is listed as a BETA, so use at your own risk, etc., etc.  But to save you the 5 minutes of reading the web page, the readme,  and the man page, I’ve tossed together a quick installation/configuration/use cheat sheet….

First, make a directory, get the gzipped tar, and expand it:

mkdir /tmp/agedu;cd /tmp/agedu
wget http://www.chiark.greenend.org.uk/~sgtatham/agedu/agedu-r8442.tar.gz
tar -zxvf agedu-r8442.tar.gz

Then, you have to compile/install it:

cd agedu-r8442/
./configure
make
make install
(optionally) make clean

Now, you get to use it.  Of course, you could now read the man page, and get all the details.  But to cut to the chase, you need to build an index file, and then either view it as text (which is boring), or dump out to html (which is really the whole point here), and view with a browser.  The author includes a method to spawn its own little web daemon, but I prefer just dumping an html file for my own use.  Here’s an example, using my home directory (note that I build the index file in /tmp just to stay clean):

cd /tmp
agedu -s /home/jpavlov/
(the “-s” does a scan at the given point, and creates the index)
agedu -H /home/jpavlov/ -R > report.html
(the “-H” generates the html output to stdout, hence the re-direct;  the “-R” deletes the index file for cleanup, since we’re done with it)

…Then open a browser, and put in the URL for the report file you created:

file:///tmp/report.html

And that’s it.  You can enjoy the visual splendor, and feel the realization that you’re wasting all that space creep over you.  Make sure to drop the author a line, and give him some feedback.  I’m off to try this out on a few NCP volumes on some OES Linux servers to see how the users’ home directories look…

Enjoy!

I got a note from Dave, asking how he could set up tftp quickly on CentOS (His happens to be 5.3, but this process should be pretty much the same on a handful of versions and distros), and get a quick configuration running.  So here you go, Dave; a tftp “cheat sheet”!

First, install the tftp server:
yum install tftp-server

Launch the gui services configuration tool:
system-config-services

…and click on the “On Demand Services” tab.  Look in the right side of the window, and make sure that it states that “xinetd.. is running“.  Scroll down and click the box for tftp.  Click “Save” at top.

Now, close out the gui tool, and run the following at the prompt:
/etc/init.d/xinetd restart

You might want to install the tftp client on your client machine for testing as well:
yum install tftp

Then, create a file on the server to test with.  For example:
echo "This is text." > /tftpboot/storedfile.txt
….which will quickly create the file in the default directory, with that line of text in it.

Then launch the client to test:
tftp localhost

…and get the file you created…
get storedfile.txt

…and you got it!

Here’s a cool trick for you folks…

If you regularly ssh to a set of servers in your server farm, but don’t like having to type out the full hostname on the command line (or can’t remember all the ip addresses), I’ve got a tip for you.

I’m sure you already know that you can type a part of a filename on the command line, and have bash complete the name.  For instance, you would type:

vi /etc/hos[tab]

…and the tab key completes the word “host” (pressing tab twice shows the remaining matching options that start with /etc/hosts, including /etc/hosts).  But did you know that bash completion can work for more things that just the filesystem?  Well, you do now.

So now let’s apply this capability to ssh, since this is something many of us commonly use.  Normally if you are trying to ssh to a server, you probably type something like this:

ssh longservernamethatyoudontwanttotype

So, if you happen to have all your servers  in your local /etc/hosts file, we can add them to the bash shell’s tab completion capability with the following command:

complete -W "`awk '{ print $2 }' /etc/hosts`" ssh

…and be very careful there to note the back-ticks and double-quotes.  In case you are wondering, what this is doing is to take the second column of your hosts file and put them into a list for completion of any ssh command.  Of course, you could add this to a startup script or some such, but I’m not going into that here for the sake of brevity.  Anyway, now if you type:

ssh long[tab]

…then the rest of the long servername will be completed there on the line.  Is that cool or what?

Alternately, if you happen to have the servernames listed in a textfile, or if you need to prefix your ssh connections with a username, you could create that server list file like this (with or without the username prefix, depending on how you wish to connect):

jpavlov@abrams
jpavlov@backus
jpavlov@crowell

…and so on.  This way, the tab completion will include your username prefix. And to utilize this particular file, you would enter something like this (of course, pointing to your particular server list, not mine):

complete -W "`cat /home/jpavlov/serverlist.txt`" ssh

…and again, be careful with the quotes and back-ticks.

I hope this makes your life easier folks, it sure has helped me… And if you haven’t figured it out already, this process applies to just about any program you want.  And, you can actually use more precise functions instead of the command method I describe here, but that’s a lot more complex than I wanted to get into in this post.  Make sure to check out the already-existing function files at /etc/bash_completion and check out complete --help for more details…

Enjoy!

A friend of mine was looking for a file using Nautilus while logged in as root on a SLE server.  He was looking for a particular file that started with a capital “S”, and simply could not seem to find it.  He thought he was losing his mind, because he was certain it was there when logged in earlier (as his regular user).

Ah-hah!  Some of you have already solved this riddle…  but do you know the underlying reasons why this is the case?  I’ll explain how it applies to bash on Suse, but it’s pretty much the same for other shells (and can be made to be the same on other distros).

You see, when you log in as regular user (meaning with a regular user profile) and do a file listing with Nautilus or ls, you see the files listed in alphabetical order, regardless of case.  When you are logged in as root, you see files listed in ASCII-like text order;  meaning all uppercase letters completely precede the lowercase letters.  It’s important to understand that these symptoms are not directly *caused* by Nautilus, ls, or their options;  in fact, these tools are simply responding to the order in which they see the files.

The magic is actually done by the “LANG” (language) variable of the current user session.  This is because for the root user, the LANG value defaults to “POSIX” (which honors the ASCII style listing), and for regular users it is set to “en_US.UTF-8” (for English US, at least; obviously yours might be a different variant of UTF-8), which is more human-style.  Check it yourself with:

echo $LANG

…which is set in /etc/sysconfig/language.  From that very file, I think the comment section explains it best:

# Local users will get RC_LANG as their default language, i.e. the
# environment variable $LANG . $LANG is the default of all $LC_*-variables,
# as long as $LC_ALL is not set, which overrides all $LC_-variables.
# Root uses this variable only if ROOT_USES_LANG is set to "yes".

So now it is all clear.  You get to choose the order in which you want to see the files.  But in the end, the standard behavior for the root user’s Nautilus or ls listing results is probably the way most sysadmins prefer (for scripts, regex, and such), and the pretty alphabetical method is probably best for regular users (more like windows).

On a side note, as a bash user, you get a set of  options for ls called LS_OPTIONS in /etc/bash.bashrc.  This file basically decides whether or not you are the root user, and if so, set the “-A” option to show “Amost All” of the files (basically all except “.” and “..”). Just wanted to mention that in case you were wondering where all your so-called “hidden” files went, too…

Why did they take unix2dos away from the SLES distribution and all standard (read: supported) repositories?  Honestly, I don’t know.  I use it all the time.  I’m pretty sure it used to be included in SLES, and it’s still in Opensuse and other distros.  Ironically, the complementary dos2unix is available in SLES as needed.  Hmm…

I’m guessing that someone high up in Suse/Novell — with far more wisdom than me — decided that we needed a slightly harder-to-memorize method of day-to-day conversion of our unix files to dos than typing “unix2dos“.  So, they made sure that we have access to the more powerful and more complex “recode” tool (which was already there anyway).  So there.

So to cut to the chase, instead of typing:

unix2dos file.txt

…like you used to, you now get to type:

recode latin1..dos file.txt

…now let me explain. What we are doing is recoding the file from type ISO-8859-1, a.k.a. “Latin1“, to type IBM-PC, a.k.a. “dos“.  As you may have figured out by now,  ISO-8859-1/Latin1 is the standard for most unix type systems.  Note the two dots in between; this is the required format.  To quote from the man page, “like BEFORE..AFTER, with BEFORE and AFTER being charsets”.

By the way, instead of typing “latin1“, you could have used any of the following aliases and types that the recode utility allows:

ISO-8859-1 819/CR-LF CP819/CR-LF csISOLatin1 IBM819/CR-LF ISO8859-1 iso-ir-100 ISO_8859-1 ISO_8859-1:1987 l1 lat1 latin1 Latin-1

And, instead of typing “dos“, you could have entered any of the following:

IBM-PC/CR-LF dos/CR-LF MSDOS/CR-LF pc/CR-LF

So there you are.  You can use this tool to convert to and from almost any type. Make sure you run recode -l to list all the types that can be recoded. And if you’re like me, you’re pretty glad that you still have this cabability… because you have scripts that export results to file on an NCP mounted volume for parsing by users with Windows and Client32, and you need to convert them to dos format so the users can view them in good ol’ Notepad.  No?  You’re not like me?

I learned lots of cool stuff last week while I was out in Provo, Utah, at Novell’s ATT Live sessions. There was simply not enough time to attend all the class sessions I wanted (in the 4 days I was there), but I’m getting through all the slide presentations and labs for the ones I missed. Phew!

Now, of course, you are not me. Your list of things you find cool certainly will not match mine, but I thought I’d throw together a short list of 5 diverse things I learned that I’m allowed to publicly reveal:

1. PolicyKit is an awesome way to delegate ownership of Xen virtual machines (as well as many other dbus style applications). This is a fairly-new package that is helping us to punch our way out of the wet paperbag that is posix. Look into it!
2. The SLES11 cluster stack is very nice, and is waaaay different than the traditional Linux and SLES10 heartbeat-only method. It will be called the “High Availability Extension” and will include LinuxHA OpenAIS (Update: See comment/reply below by Beekhof), cLVM, OCFS2, DRBD, and IPVS. It will be an add-on pack (I believe they will be called Enterprise Extensions) in some fashion, with specific up-sold support (though the download will apparently still be free).
3. As of SLES11, OCFS2 is truly posix-accurate. This means you could use it as a standard user-style filesystem if you wanted to… Fun!
4. The mountains in SLC and Provo are absolutely beautiful, but still catch me off-guard. In Michigan, if you are standing outside, and you look over to your right and see something *that* big next to you, you need to run.
5. The Mooty toolset is very cool. Mooty is a suite of tools developed by the Novell training team for rapid manipulation of their training machines. Let your imagination go wild with that one. It is clever, fast, easy. I understand they are going to turn it out into the open source as a project someday soon. I’m on the list so I’ll let you know when it happens.

There are so many more cool things, like Domain Services For Windows (Active eDirectory?), all the new developments in ZenWorks 10, the Platespin stuff, and on and on…

Thanks to everyone at Novell for the wonderful time. And thanks to all the fellow participants for the great company and conversation.

…and I’m not happy about it.

Oh, its not really Suse’s fault directly. Or Opensuse’s fault specifically. In fact it is a combination of faults, including my own. But mostly, it is Novell’s fault.

You see, I cannot live without iFolder. And I realize that now, more than ever.

Aside: Here are two great links for catching up on — and following the progress — this conundrum:

• Novell Forums, iFolder
• The now-infamous bug report

I live in a world of mostly Linux computers, with a handful of Windows computers, and I use iFolder (as you’ve probably noticed from past posts) to keep my personal data world perfectly in sync between these OSs.

When Opensuse 11.1 came out a couple months ago, I jumped right on it as I always do for their new releases. As nice as it was/is, it took me a frustrating week or so to realize that no matter how much I hacked at it, I could not make the iFolder stuff work on my new installation. Argh.

Why? It’s because of many of the aspects of iFolder (and the sub-requirements thereof) require GTK stuff (GNOME stuff) from the last release. If you run KDE, you can back-rev enough of the components to get by. Well, I don’t and I can’t. And I won’t. Why in the heck can’t there be a command-only version of iFolder, disassociated from the GUI (like JungleDisk)? If that were the case, I’d certainly have been able to get it working as a background-only process, and that would be fine. In fact, that would be preferred. In fact, now that I think about it, that would be awesome.

Now, a couple months later, I’m still forced to try and remember that every time I change a file on my Opensuse 11.1 laptop, I need to copy it up to my iFolder server Web Access interface. Jeez, like I can remember to do that…

So, as home/documents directories on my two OSs grow further and further astray, I become more and more frustrated, and feel more and more out of control. I have come to the conclusion that I *have* to go back to Opensuse 11.0, where I am able to hack together the iFolder client to work just fine.

Honestly folks, this is just a rant. No point to make other than how frustrated I am. And how I wish Novell would have thought this through beforehand. And how I wish Novell would have kept feeding the source code to the public (as required) so that this would not (or at least should not) have happened. And how I wish somebody smart were still compiling the code for iFolder versions 3.4 or 3.6 or 3.whatever for the new Opensuse 11.1.

I’m going to keep hoping, but I’m not holding my breath. Now where’d I leave that 11.0 net-install iso….?

Argh.

UPDATE, 20090323: There’s hope!!! See this:

http://zonker.opensuse.org/2009/03/23/update-on-ifolder/

UPDATE, 20090331: Source code has been made available again…

http://apps.sourceforge.net/mediawiki/ifolder3/index.php?title=Subversion_Instructions

UPDATE, 20090401: No fooling, the iFolder site has been re-launched, and the project re-vamped…

http://www.ifolder.com/ifolder

Okay readers, I need your help.

I have been listening to LugRadio for its entire 5-season run, and was really saddened to hear that they’ve gone off the “air” mid-2008.

Some background on me… You see, I ride a motorcycle for my daily commute most of the year (since I live in the mid-west US, some/much of the winter is too brutal to ride).  I don’t listen to any entertainment while riding the motorcycle (other than being entertained by the interconnection with the world), so I wait until the non-riding season to catch up on all my podcasts in my car. As of this morning, I am *finally* up to the penultimate LugRadio episode (depending on whether or not you count the Lug Radio Live as an episode proper, which Aq does, and Jono does not, according to statements in season 5, episode 22).

Anyway… So here I am, almost to the end of the “car” season for me, and almost at the end of my cache of LugRadio. But, soon, I’ll be needing my fix of… something… But what will it be?

So please tell me… to what podcast do *you* listen? Are there any with the same entertainment value? With the same intellectual value? With the same technical level?

Drop me an email or just post a reply. And thank you for helping me in my rehabilitation…

Addendum: I feel like the the folks over at Tectonic felt my pain… check out this article!

Here is my version of a “cheat-sheet” for installing iFolder3.6 on SLES10sp2 (It is based on — and is almost the same as — my earlier cheat-sheet based on iFolder3.6 on Opensuse10.3, with minor differences). This cheat-sheet kinda’ leaves you out on your own once you get to the part about running the configuration script (see below), but I don’t want to over-do it here and try to help you with every option you could possibly choose. Other than that, I pretty much cover all the needed setups and caveats… I hope… Good luck!

First, install SLES10sp2, mostly with the defaults. I noticed that when installing SLES10sp2, since it is a Gnome-based system, then you’ll already have the mono-core and some other needed mono modules. You might want to be mindful of partitioning (beyond your usual method or the defaults), and perhaps allow for a special iFolder data store. No need to set up ownership or permissions for the special store, as the configuration script will handle that later.

Host naming is pretty critical with iFolder. You need to plan for what name the iFolder server will be known by, both inside and outside of your internal network. Make sure the server and clients are able to resolve this/these name(s)!

Now, install some other pre-req’s for ifolder:
yast -i apache2
(…you may want to set chkconfig apache2 on)
yast -i mod_mono
(…which auto-installs xsp…)

…and any other packages necessary (mono-core should already be on a gnome-based server) to satisfy the requirements for the following packages, especially if you did a restricted/limited install…

Now get and install the main ifolder packages (under the SLE_10 section), (thanks, martijn!) in order:
(…log4net should already be there, but be sure…)
rpm -Uvh libflaim-???????.i586.rpm
rpm -Uvh libflaim-devel-?????.i586.rpm
rpm -Uvh simias-svn-?????.i586.rpm
rpm -Uvh ifolder3-server-svn-3.6.???????.i586.rpm

Run /usr/bin/simias-server-setup (as instructed by the ifolder3-server rpm install), and follow the prompts. This setup script will allow you to set the storage point, the admin password, the authentication source (ldap, local, etc), etc.

If you are setting this up for the first time, I encourage you to choose local authentication (instead of ldap) and learn how the system works. The only caveat there is that if you intend to setup more than one iFolder server in a master/slave configuration, you must use LDAP for authentication; so be prepared if that applies to you.

One important thing to be aware of while running the script is that you must enter valid hostnames when prompted for internal and external addresses/names. If you don’t have appropriate DNS names for the system (like if it’s a lab server or something), make sure you use valid IP addresses. You’ll know that you did it wrong if you cannot reach it later…

***After using the simias-server-setup configuration script, if you had chosen the “Configure Apache” option, you may need to fix a few things (I did) like this:

cd /etc/simias/apache/default/
mv simias_server.conf simias_server.conf.dontuse

cd /etc/simias/apache/
cp ifolder_apache.conf /etc/apache2/conf.d/

Now, make sure to modify the firewall configuration file:
vi /etc/sysconfig/SuSEfirewall2
…to allow for http port(s) 80 and 443, and restart the firewall with rcSuSEfirewall restart. Or use the Yast2 firewall module instead, if you want to do it graphically. Either way, you *do* want people to be able to reach your new service, right?

Finally, restart or start apache:
rcapache2 restart

Now the server is done! You can administer it at the following URL:
http://servername/admin
…or access it as a user (after you configure one) at:
http://servername/ifolder

Enjoy!