Spacewalk, it’s pretty damn awesome. Or at least, I think it is. It’s an open source linux systems management solution from Redhat (GPLv2).

Once you get spacewalk up and running, you’ll be amazed by some of the things it does. It can push config files, packages, inventory systems, group them and allow you to work exclusively with those groups in a very easy way. That’s only scratching the surface of what spacewalk is capable of.

I like it because I can setup custom channels where I can push custom software to each of my servers. From time to time though, I notice that the repos don’t really rebuild automatically. If you look at the “details” section of your channel, you’ll notice something like this

The times don’t match. It probably means that the taskomatic daemon is not running or is running but isn’t really pulling tasks from the database.

To verify, login to sqlplus and run this query

sqlplus spacewalk/spacewalk@xe

SQL*Plus: Release 10.2.0.4.0 - Production on Sat Nov 13 14:14:00 2010

Copyright (c) 1982, 2007, Oracle. All Rights Reserved.

Connected to:
Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production

SQL> select * from rhnTaskQueue;

ORG_ID TASK_NAME
---------- ----------------------------------------------------------------
TASK_DATA PRIORITY EARLIEST
---------- ---------- ---------
1 update_errata_cache_by_channel
143 0 13-NOV-10

1 update_errata_cache_by_channel
122 0 12-NOV-10

1 update_errata_cache_by_channel
208 0 13-NOV-10

ORG_ID TASK_NAME
---------- ----------------------------------------------------------------
TASK_DATA PRIORITY EARLIEST
---------- ---------- ---------
1 update_errata_cache_by_channel
122 0 13-NOV-10

Notice how some tasks are older? This table should almost always be empty or only have data for a small period of time as the name suggests.

Restarting taskomatic is as simple as


[root@spacewalk init.d]# ./taskomatic stop
Stopping RHN Taskomatic...
Stopped RHN Taskomatic.
[root@spacewalk init.d]# ./taskomatic start
Starting RHN Taskomatic...

Wait about 10 minutes, because that’s the polling time for taskomatic, and then check the database again. There should be no rows


SQL> select * from rhnTaskQueue;

no rows selected
SQL>

Also check the spacewal UI and look for something like this

or

Spacewalk is still very much in its infancy but it shows great promise and there is a great community of people who are willing to help and are dedicated to making it a rich and feature full product. Spacewalk 1.1 was released recently and we haven’t had a chance to upgrade yet but I continue to see great things coming from spacewalk and that makes me happy.

I always find these commands handy when working with apache.

Part of any VirtualHost config involves making the right directories and you can make your job easier by using curly braces. I suppose you could call it regular expressions. I don’t actually know the technical terms for it. I know it works in bash which is what I use on a daily basis.

Learn how to create directories without having to issue multiple mkdir commands. This is a pretty simple one.

mkdir -p /path/to/some/vhost/docs

This is fairly straight forward. Make the parent directories if they don’t exist. So if /path/to/some/vhost/docs is what you want, and /path or any of it’s children don’t exist, then it will get created. It’s a fairly safe command because it intelligently checks before creating directories.

This example is a bit more complicated but it’s awesomeness will blow you away. I used this when I was making virtualhosts for multiple domains or even sub domains of the same parent.

mkdir -p {sub1,sub2,sub3}.domain.com/{docs,logs,cgi-bin}

or

mkdir -p www.{domain1,domain2,domain3}.com/{docs,logs,cgi-bin}

that command will create all your directories in the appropriate hierarchy so that you don’t need to issue multiple mkdir commands. It will create the parent directories for you as well. Here is what it does.

$ find .
.
./www.domain1.com
./www.domain1.com/cgi-bin
./www.domain1.com/docs
./www.domain1.com/logs
./www.domain2.com
./www.domain2.com/cgi-bin
./www.domain2.com/docs
./www.domain2.com/logs
./www.domain3.com
./www.domain3.com/cgi-bin
./www.domain3.com/docs
./www.domain3.com/logs

You can also do that with ls.

$ ls -d www.domain{1,2}*
www.domain1.com    www.domain2.com

Or even with rm

$ rm -vr www.domain{1,3}*
www.domain1.com/cgi-bin
www.domain1.com/docs
www.domain1.com/logs
www.domain1.com
www.domain3.com/cgi-bin
www.domain3.com/docs
www.domain3.com/logs
www.domain3.com

Enjoy!

You should know that I only recommend doing this on systems that you ABSOLUTELY trust. If you have any doubt what so ever, do NOT continue.

I never thought i’d actually need this but i ended up actually providing it as a solution for securing database accounts.

To get this working on CentOS 5, I had to do the following

# yum install xinetd authd

authd is an xinetd service and authd is the RFC 1413 identd service

Out of the box, authd comes a little more secure than I expected. It’s not bad but it’s definitely a hindrance for other systems when they don’t know what to send.

/etc/xinetd.d/auth will come by default with

server_args = -t60 --xerror --os -E

This tells inetd to expect the ‘uname’ instead of ‘UNIX’ as the OS name. It’s great that it offers this option but I don’t know if all identd clients need to know what OS it is. You can leave it in if you like. Lastly, it tells identd to encrypt the username and then send it. I’m not sure how many identd clients can handle that.

I changed it to


server_args = -t60 --xerror

start or restart xinetd and you should see 113 listening.

I’m a lazy guy so I can’t be bothered to open more than one connection to a server. You can open two if you prefer.

I login and start tcpdump


tcpdump -i lo -nn "port 113" &
telnet localhost 113

It should show you distinctly what port two ports are involved in the connection you just made.

IP 127.0.0.1.SOURCE_PORT_NUM > 127.0.0.1.113

Next type in “SOURCE_PORT_NUM,113″ and hit Enter. Note that “SOURCE_PORT” here is a NUMBER not actually “SOURCE_PORT”

Amidst all the messy tcpdump output, you should see a line

SOURCE_PORT_NUM , 113 : USERID : UNIX :root

That shows you that identd is working properly. At least locally.

So if you ever find any of this useless knowledge helpful, let me know.

Unix/Linux admins are taught to hate identd because it’s pretty much the least secure protocol but I have to believe that it has a place in an environment that is completely trusted. You don’t have random users logging in or random accounts being created.

I think the overall advantage here is that you can use this to provide an additional layer of security across your trusted enterprise.


© 2007 wp | anoopdotnet | iKon Wordpress Theme by Windows Vista Administration | Powered by Wordpress