Your Linux Guy .com

Believe it or not, there are valid reasons why you might want to disable the firewall service on a Suse Linux Enterprise Server (SLES).  For instance, avoiding NCP time-outs on client connections for an OES/SLES server.  If you just want to know how to disable the firewall in most modern incarnations of SLES, read on…

The examples given here are assuming you are remote to the server.  Of course, you could do all of this locally on the console, or adapt my instructions to the gui “Yast2″, but I’m going non-gui here for simplicity.

First, shell into the box, and su to root.

Method 1:

Launch the Yast non-gui firewall module:
yast firewall

To change to startup setting to “Manually”:
“Alt + m”

Optionally, to stop the service right now if running:
“Alt + t”

To complete the change:
“Alt + n”

To accept and finish:
“Alt + a”

Method 2:

To disable the service at next startup:
chkconfig SuSEfirewall2_setup off

Optionally, to stop the service right now if running:
rcSuSEfirewall2 stop

I hope that helps!  Now, if you want to argue about how one should never disable the firewall, drop me a line…

This article is written in a story-like retrospective fashion.  (Update, 20100128, morning: Now with a happy ending! See below…)  It’s a chain of events that took me from a happy Openfiler user, to and extremely angry Openfiler user, to a cautious Openfiler user.  So let’s begin.  “It was a dark and stormy night…”

It had been almost a year since I patched my Openfiler 2.3 server, and some significant updates had been released in that time.  So after planning an outage window, I set out to apply the queued batch of updates (including mkinitrd and a kernel or two, more on that later).  It seemed such a simple task….

After the patches were applied, the Openfiler server would not boot.  Instead, it spewed out more errors than I could read to the console, ending with a kernel panic.

So I booted to the Openfiler install cdrom, and entered rescue mode with “linux rescue“.  Fortunately, it discovered and mounted all my partitions, and I was able to run with networking in order to reach the package sources or other sources/destinations if I should need them.

I noticed that the errors I had seen on the console pointed me toward missing drivers in the initrd, so I started looking there.  While poking around, I think I noticed that the latest update bundle had re-compiled all my initrd’s in /boot. I’m not actually 100% sure about that now in hindsight, but it’s not important now.  Anyway, I de-constructed one of the initrd’s this way to see what was up:

mkdir /tmp/temp
cd /tmp/temp
cp /boot/initrd-2.6.29.6-0.15.smp.gcc3.4.x86_64.img initrd-2.6.29.6-0.15.smp.gcc3.4.x86_64.img.gz
gunzip initrd-2.6.29.6-0.15.smp.gcc3.4.x86_64.img.gz
cpio -i --make-directories < initrd-2.6.29.6-0.15.smp.gcc3.4.x86_64.img
ls -l
ls -l lib/

Hmm.  No drivers there.  Should be a bunch of *.ko files…  Hmm…

I decided to roll back;  so I ran conary to revert to the state before the update  (Run “conary rblist” to figure out the number of the point-in-time to which to roll back, then “conary rollback (number)” to actually do it.  See this wiki page for details).

For some reason, this did not repair all my initrd’s, but it did seem to give me a working mkinitrd script (in hindsight, I did not think to analyze it or keep a copy of it… drat).  So I was now able to hand-build a working initrd for one of the kernels (the most recent before the update) with this command:

mv /boot/initrd-2.6.29.3-0.3.smp.gcc3.4.x86_64.img initrd-2.6.29.3-0.3.smp.gcc3.4.x86_64.img.bad
mkinitrd /boot/initrd-2.6.29.3-0.3.smp.gcc3.4.x86_64.img 2.6.29.3-0.3.smp.gcc3.4.x86_64

And now, I was able to reboot into this kernel with my new working initrd…. and this time I made backups of it in my /home directory!

So I proceeded to re-apply the patches bit by bit.  I quickly realized that the dreaded kernel update was a requirement as part of the major Openfiler update, so it came back with the re-run of the last few updates anyway.  But this time, I was ready.  I modified the /boot/grub/menu.lst to use my old trusty kernel and initrd, (default=1), and make sure my hand-made initrd was in place.  Ok, good.  Reboot.  Right.

Back up in my older kernel (phew!), but with my newer kernel installed, I troubleshot…  I tried to build my own initrd against the new kernel, but I kept getting errors like this for each needed module:

/usr/bin/strip: /lib/modules/2.6.29.6-0.15.smp.gcc3.4.x86_64/./kernel/drivers/rtc/rtc-lib.ko: File format not recognized

I dove in to the /sbin/mkinitrd and found the cause.  There are some lines in an “if” block that optionally call “strip” if present, and that is where it seems to err out.  If “strip” is not present, it just copies the module, like I want.  Hmm.  I don’t know if strip was there before or not, or if the mkinitrd suddenly has this new “if” block, and I don’t care.  I commented it out to look like this:

for MODULE in $MODULES; do
#    if [ -x /usr/bin/strip ]; then
#        /usr/bin/strip -g $verbose /lib/modules/$kernel/$MODULE -o $MNTIMAGE/lib/$(basename $MODULE)
#    else
cp $verbose -a /lib/modules/$kernel/$MODULE $MNTIMAGE/lib
#    fi
done

…and re-built my initrd for the latest kernel like this:

mv /boot/initrd-2.6.29.6-0.15.smp.gcc3.4.x86_64.img initrd-2.6.29.6-0.15.smp.gcc3.4.x86_64.img.bad
mkinitrd -f -v /boot/initrd-2.6.29.6-0.15.smp.gcc3.4.x86_64.img 2.6.29.6-0.15.smp.gcc3.4.x86_64

…and no more errors!  Yay!  I modified the /boot/grub/menu.lst back to use my new kernel and initrd, (default=0), and I re-booted into it with no kernel panic! Yay!

And that’s my story.  I really hope this helps someone out there…

UPDATE, 20100127, evening:  On the Openfiler forums, there is talk of a fix.  To quote a Rafiu, “This was due to a strange situation where 64-bit version of binutils was not built and the group update succeeded regardless.

We have now resolved this issue. Apologies to all that were affected by it. “

I have not yet tested this, but I do see that the latest binutils is in the update list now.  More to come…

UPDATE, 20100128, morning:  Yes.  The latest set of updates at this time, *including* the correct set of binutils (2.17.50.0.6-7-0.0.2) for 64-bit, worked perfectly, and my server is still running as smoothly as ever after rebooting.  Hooray.  Though I will never get that Saturday night back that I spent chasing my initrd all over the place, but there you go…

This question came in from Steve in a comment:  “…I am looking for a way to run the “rug lu” command and have it dump the output my local machine to look over and see what updates I have ahead of me…”

So I replied, but then I thought of alot more stuff… so much more in fact, that I thought it deserved its own post…  So here you go, an “extended play” version of my reply…

For OpenSuse servers…

Please see this post:  http://yourlinuxguy.com/?p=324

That is exactly what I was going for in the post linked above.  If you download that script I mention there in that post, then change it to executable (for instance, chmod 700 filename), then run it, it will generate a comparison and dump the results to screen and output file, and tell you where the file is.

The script will not actually update your system (in the current state); it will only report about potential updates. But, if you get more brave, you can go in the file and un-comment the zypper lines I commented out that actually update the system…  Or change them to rug lines…  Which leads me to…

For SLES/OES servers…

Just do this:
rug lu > /tmp/lu.txt

…then go look at the file with:
less /tmp/lu.txt

…Or, you could have it emailed to yourself like this:
rug lu |mailx -s "Updates from $HOSTNAME" root

…of course, that assumes that you are having root mail sent off the box (see this if you’re not).  Otherwise you use your email address instead of root.

But what if you want to limit the updates list?  Perhaps something more specific; to report only that in which you are interested in updating?  See these examples (note that you can change the rug catalog to taste, of course, depending on your version):

rug lu -t patch SLES10-SP3-Updates OES2-SP2-Updates |mailx -s "Updates from $HOSTNAME" root

By adding a grep statement to block out the “optional” lines, the result is even cleaner.  Here’s an example:

rug lu -t patch SLES10-SP3-Updates OES2-SP2-Updates |grep -v optional|mailx -s "Updates from $HOSTNAME" root

On the other hand, by only *including* the lines you want (instead of excluding those you don’t), you lose the headers and separators, and only get the lines in which you’re interested (if any).  Here’s an example:

rug lu -t patch SLES10-SP3-Updates OES2-SP2-Updates |grep -e security -e recommended|mailx -s "Updates from $HOSTNAME" root

Or if you were to be running this in a mass-batch (hmm… future post…) to a bunch of servers or a cron job, and just don’t want an email at all if there are no results (and you *do* want an email if there *are* results):

RESULT=`rug lu -t patch SLES10-SP3-Updates OES2-SP2-Updates |grep -e security -e recommended`;if [ "XX$RESULT" != "XX" ];then echo "optional updates:" $RESULT |mailx -s "Updates from $HOSTNAME" root;fi

Okay now, that’s good; but here’s a prettier version of the same…  Okay, the command itself is uglier, but the resulting email is prettier at least.  The above one doesn’t format the results as nicely as I like (losing all the line returns), so I had to make use of a temp file to maintain the output formatted with returns:

rug lu -t patch SLES10-SP3-Updates OES2-SP2-Updates |grep -e security -e recommended>/tmp/ruglu.txt;RESULT=`cat /tmp/ruglu.txt`;if [ "XX$RESULT" != "XX" ];then cat /tmp/ruglu.txt|mailx -s "Updates from $HOSTNAME" root;fi

And that’s about it, with a couple closing thoughts:  Remember, it’s definitely a good idea to do a “rug ping” before doing this, to wake it all up, so you’re not waiting in silence for each command to run while it wakes up.  Then if you actually need updates, do this:

rug up -y -t patch -g security -g recommended SLES10-SP3-Updates OES2-SP2-Updates

Do you feel updated?  I do.

…module compilation process.

Seriously, folks.  I know there are others of you out there, like me, who upgraded to Opensuse 11.2 (the latest at the  time of this writing), without concern that VMware Server 2.0.2 (also the latest at this writing) may or may not run on it.  Well guess what: it doesn’t.  Well, not without help, that is.

To cut to the chase, as I write this, the problem is that VMware Server 2.0.2 will not work with the newest kernel and libraries that are shipped with Opensuse 11.2, version 2.6.31.x.and.so.forth.  So I found some work-arounds while Googlin’, that I wanted to record for posterity.  Here’s what I did:

1. Go to this post from Radu Cotescu.  Read up.  Note that Radu’s post, problem, and fixes are all about Ubuntu.  Do not fear.  (Post-publish update, 20100119:  See http://radu.cotescu.com/2010/01/19/how-to-install-vmware-server-ubuntu-fedora-opensuse/ for a new version that I have not tested yet.)
2. As he instructs in his step 1, download the VMware 2.0.2 tgz file from VMware themselves (version 2.0.2-203138 at this time), and drop it in a directory like /tmp/vmware.  DO NOT decompress the tgz file!  The script will do it for you.
3. Get Radu’s script, and as instructed in his step 2, drop it in the same folder as the VMware tgz file, for instance, /tmp/vmware.
4. Here is where we slightly vary from the plan… open the script up in a text editor (vi, gedit, emacs, etc.), go down to the “install” section around line 76, and comment out all the “dpkg-query” checks from line 77 to line 95.  Save, and quit.  Funny… but I don’t remember those checks being there a month or so ago, so he may be changing them from day to day.  Tread carefully, and don’t necessarily trust my indicated line numbers.
5. Make sure we have the necessary script support software installed;  you need your kernel version “devel” package (for me, since I have kernel-pae, I need kernel-pae-devel), kernel-source, linux-kernel-headers, gcc, and make.  Use zypper in <package-name> to get them installed.
6. Now return back to Radu’s step 3, and complete his commands as listed.
7. If all goes well, when you follow his instructions, it will compile everything, and launch you right into to the VMware installation, and continue into the configuration.  Make sure you have your VMware registration code handy.  Oh, and of course, ignore that GCC version mis-match warning… And you may want to do a chkconfig vmware off when you’re done, I always do.

So there you go.  That’s the only way I could get it all to work together.  But if you know of a better way, or if I missed something, please share it with the group!  I assume that VMware will get a corrected version out in the near future that will mitigate this issue, but in the meantime, it’s a real life-saver.  And many, many thanks to Radu and any others involved….

Happy Holidays to all my readers, customers, family, and friends (and even enemies for that matter), from your Linux guy at YourLinuxGuy.com.

And yes, I mean holiday*s*, as in plural.  I’m not saying that because I don’t want to say “Merry Christmas”; though if that applies to you, then I wish that to you too.

But I also wish you a Happy Winter Solstice (today!), Happy Hanukkah (though it just ended), etc.;  what I mean is, $pleasantAdjective $applicableHoliday to $you and $you.yours!!

I hope you don’t mind me taking this one post to thank you all, and offer best wishes to you and yours.

I very much appreciate all your participation ( comments, questions, etc., ), but most of all I appreciate that you take time out of your busy day to read my little… well, whatever this is.

And Happy New Year!  May we all have success and happiness in the year to come.

(This article was updated for technical accuracy, and tested, 20100109.  I’ve been chasing packages, across URLs, across the ‘Net… Ugh… )

My previous iFolder-related cheat-sheets here on this blog have been reasonably popular  (see the ifolder3 category for reference).  I get quite a few comments and requests for various configuration alterations and such, but I cannot handle them all.  In fact, since I wrote most of my previous articles on iFolder 3.6,  I have had a small handful of readers asking me for iFolder 3.7 articles on various server platforms, but I just ran out of time in getting it together for posting the articles before iFolder 3.8 came out.  Sorry.

So here we are.  And now I didn’t want to delay.  Since iFolder 3.8 came out in the last week of November (about a week ago at this writing), I’m eager to get to it without much ado.  So let’s jump right in….

Preparation

For this quick-setup cheat-sheet, we’re going to install and configure iFolder 3.8.0 (32-bit) with a local user database (meaning no ldap, sorry) on an OpenSuse 11.1 server (32-bit) running Apache2 with SSL.  Just to repeat, all the examples in this article are on a 32-bit install; it shouldn’t be that hard for you to guess at the 64-bit URLs and such if you need to.

So let’s start with a clean, patched Opensuse 11.1 box (at the time of this writing, iFolder 3.8 server is only supported on Opensuse 11.1).  Name resolution is paramount with iFolder, so make sure to edit and validate the hosts file, and be sure that the server’s short and long name (the one you intend to use to reach the iFolder service) are both there with the permanent static address.  Here’s a fictitious example of a line in my /etc/hosts:
290.32.2.14 test.yourLinuxGuy.com test

Section 1: Install and configure worker-mode apache2 with SSL

If this is a fresh install, make sure you install the worker-mode Apache2 (the docs recommend worker instead of pre-fork).  If you already had Apache2 pre-fork, you may or may not want to remove it before continuing, it’s up to you.  To install, do this:
zypper in apache2-worker (agree to the packages it requires)

By default, openssl should already be on the machine;  so let’s move right on to getting SSL configured.  For a full explanation, you can either follow my earlier Apache2/SSL post at: http://yourlinuxguy.com/?p=55, or see the iFolder project SSL support doc “ifolder_ssl.odt“, available from the community site.

Here, for the sake of brevity, I’ll spare you all that; and give you just the cut-and-dried example commands you need to get SSL up and running, without any real explanation (of course, change my certificate example values to suit you).  If you follow these, you’ll have a working Apache2 with SSL before we move on to the iFolder part:

/usr/bin/gensslcert -c US -s MI -l "Southfield" -o "Your Linux Guy Test" -e jpavlov@yourLinuxGuy.com -d -n test.yourLinuxGuy.com
vi /etc/sysconfig/apache2 (Add SSL to the APACHE_SERVER_FLAGS section)
cd /etc/apache2/vhosts.d/
cp vhost-ssl.template vhost-ssl.conf
vi vhost-ssl.conf (un-comment and change “ServerName” to match name in /etc/hosts, and optionally “ServerAdmin” to your email address)
rcapache2 stop
rcapache2 start
vi /etc/sysconfig/SuSEfirewall2 (to open ports 80 and 443, set FW_SERVICES_EXT_TCP="80 443")
rcSuSEfirewall2 restart

Section 2: Get and install other support software

(This section was re-vamped after the 2.4 mono stuff got moved all around in the places on which I was relying.  In the previous version, I had you configuring a repository for Mono, but now we’re just going to install it all manually.)

The iFolder software needs a supporting cast, since Mono 2.4.x and Simias really do much of the behind-the-scenes work.  So, let’s get all that installed.  Here is one insanely long rpm command that will get all you need in one shot (except for log4net, which is below that) as long as the packages are still out there at the site.  Please let me know if they aren’t…

rpm -Uvh http://ftp.novell.com/pub/mono/archive/2.4.3/download/openSUSE_11.1/i586/apache2-mod_mono-2.4.3-22.61.i586.rpm http://ftp.novell.com/pub/mono/archive/2.4.3/download/openSUSE_11.1/i586/mono-core-2.4.3-26.7.i586.rpm http://ftp.novell.com/pub/mono/archive/2.4.3/download/openSUSE_11.1/i586/mono-data-2.4.3-26.7.i586.rpm http://ftp.novell.com/pub/mono/archive/2.4.3/download/openSUSE_11.1/i586/mono-data-sqlite-2.4.3-26.7.i586.rpm http://ftp.novell.com/pub/mono/archive/2.4.3/download/openSUSE_11.1/i586/mono-web-2.4.3-26.7.i586.rpm http://ftp.novell.com/pub/mono/archive/2.4.3/download/openSUSE_11.1/i586/mono-winforms-2.4.3-26.7.i586.rpm http://ftp.novell.com/pub/mono/archive/2.4.3/download/openSUSE_11.1/noarch/xsp-2.4.3-22.27.noarch.rpm
zypper in log4net

Section 3: Get and install iFolder 3.8 server

Now it’s time to get the iFolder software installed, which is what we’re here for in the first place (please note that I fixed these URLs too, on 20100109):

mkdir /tmp/ifolder3.8
cd /tmp/ifolder3.8
wget http://downloads.sourceforge.net/project/ifolder/iFolder%20Server%20Plugins/3.8.0/11.1/novell-ifolder-enterprise-plugins-3.8.0.9328.1-3.1.i586.rpm?use_mirror=voxel
wget http://downloads.sourceforge.net/project/ifolder/iFolder%20Server/3.8.0/11.1/ifolder3-enterprise-3.8.0.9328.1-3.1.i586.rpm?use_mirror=voxel
rpm -Uvh ifolder3-enterprise-3.8.0.9328.1-3.1.i586.rpm
rpm -Uvh novell-ifolder-enterprise-plugins-3.8.0.9328.1-3.1.i586.rpm

Section 4: Configure iFolder 3.8

At this point, everything is installed, but nothing really works.  You’re almost there, but you need to configure everything.  So, I’ve just posted the remaining configuration commands below, but linked the output in linked files to try to keep the clutter down in this post (too late!).

/usr/bin/simias-server-setup
(click here to see example simias-server-setup_output)

ifolder-admin-setup
(click here to see example ifolder-admin-setup_output)

ifolder-web-setup
(click here to see example ifolder-web-setup_output)

Now, all that’s left is to restart Apache2 to actuate the changes:
rcapache2 restart

Conclusion

Now you are done.  Go to the admin site at:

https://<servername>/admin

…and the general ifolder web site at:

https://<servername>/ifolder

I’ll leave it to you download the client and configure it.  I hear it’s cosmetically pretty, but I haven’t seen it yet. Why haven’t I seen it yet? Because of this bonus tidbit:  The iFolder 3.7.2 client seems to work with iFolder 3.8 server (at least it does so far!), so I haven’t fully migrated yet. I’m sure there’ll be more on that later.  However, the documentation seems to suggest that the opposite will not be the case.

Whew!  That was alot.  I hope it helps.  As always, drop me a line if you find anything wrong in here, or have something to contribute yourself.

First, see this post for background…  don’t worry, I’ll wait…  Okay, you’re back?  Good.  Let’s continue…

At the time of this writing, t’is the night before Opensuse 11.2 is released.  And I just happened to find a mirror or two that were set up in advance, and decided to have some fun.  I was hoping to easily duplicate my Opensuse 11 to 11.1 in-place upgrade cheat sheet, but as it turned out, this time it is not so easy.

So below, please see my working scratch-pad of my in-place upgrade of Opensuse 11.1 to 11.2 cheat sheet.  Remember, the important point here is that we want to be able to do this without downing the server…  oh, that’d be the easy way…  *We* want to be able to do it without having to drive to the remote site where the server sits, get it?

By the way, Suse themselves, for the first time, is “supporting” an in-place upgrade using their prescribed method.  I have not tested this method, but it looks very simple and straight-forward;  I may change to doing it their way once I get some time to test it out.  Their official method can be found here:  http://en.opensuse.org/Upgrade/11.2

Caveats:  At the time of this update (see below), I’ve only tested it on two 32-bit machines and two 64-bit machines…  So, please realize, you’re doing this at your own risk…  don’t do this to your machine without backing up, or imaging it in the first place! Honestly, while figuring this out, I just kept throwing packages at it until it worked, so some of these might not be needed, but I know it worked for me…. And in the end, they all get updated anyway, right?

So here we go….

For both 32-bit and 64-bit:

(Update @ 200911131438 for addition of 64-bit)

cd /etc/zypp
mv repos.d repos.d.old
zypper ar http://download.opensuse.org/distribution/11.2/repo/oss openSUSE-11.2-Oss
zypper ar http://download.opensuse.org/distribution/11.2/repo/non-oss openSUSE-11.2-Non-Oss
(optional) zypper ar http://packman.iu-bremen.de/suse/11.2 packman

For 32-bit ONLY:

rpm -Uvh http://download.opensuse.org/distribution/11.2/repo/oss/suse/i586/libselinux1-2.0.80-5.2.i586.rpm
rpm -Uvh http://download.opensuse.org/distribution/11.2/repo/oss/suse/i586/liblua5_1-5.1.4-6.2.i586.rpm
rpm -Uvh http://download.opensuse.org/distribution/11.2/repo/oss/suse/i586/liblzma0-4.999.9beta-2.2.i586.rpm
rpm -Uvh http://download.opensuse.org/distribution/11.2/repo/oss/suse/i586/libpopt0-1.13-4.2.i586.rpm
rpm -Uvh --nodeps http://download.opensuse.org/distribution/11.2/repo/oss/suse/i586/rpm-4.7.1-6.7.3.i586.rpm
rpm -Uvh --nodeps http://download.opensuse.org/distribution/11.2/repo/oss/suse/i586/libzypp-6.21.2-1.1.1.i586.rpm
rpm -Uvh http://download.opensuse.org/distribution/11.2/repo/oss/suse/i586/libreadline6-6.0-18.3.i586.rpm
rpm -Uvh http://download.opensuse.org/distribution/11.2/repo/oss/suse/i586/libaugeas0-0.5.0-2.2.i586.rpm
rpm -Uvh http://download.opensuse.org/distribution/11.2/repo/oss/suse/i586/libstdc++44-4.4.1_20090817-2.3.4.i586.rpm
rpm -Uvh http://download.opensuse.org/distribution/11.2/repo/oss/suse/i586/satsolver-tools-0.14.10-1.1.1.i586.rpm
rpm -Uvh http://download.opensuse.org/distribution/11.2/repo/oss/suse/i586/zypper-1.2.8-0.1.3.i586.rpm

For 64-bit ONLY:

rpm -Uvh http://download.opensuse.org/distribution/11.2/repo/oss/suse/x86_64/libselinux1-2.0.80-5.2.x86_64.rpm
rpm -Uvh http://download.opensuse.org/distribution/11.2/repo/oss/suse/x86_64/liblua5_1-5.1.4-6.2.x86_64.rpm
rpm -Uvh http://download.opensuse.org/distribution/11.2/repo/oss/suse/x86_64/liblzma0-4.999.9beta-2.2.x86_64.rpm
rpm -Uvh http://download.opensuse.org/distribution/11.2/repo/oss/suse/x86_64/libpopt0-1.13-4.2.x86_64.rpm
rpm -Uvh --nodeps http://download.opensuse.org/distribution/11.2/repo/oss/suse/x86_64/rpm-4.7.1-6.7.3.x86_64.rpm
rpm -Uvh --nodeps http://download.opensuse.org/distribution/11.2/repo/oss/suse/x86_64/libzypp-6.21.2-1.1.1.x86_64.rpm
rpm -Uvh http://download.opensuse.org/distribution/11.2/repo/oss/suse/x86_64/libreadline6-6.0-18.3.x86_64.rpm
rpm -Uvh http://download.opensuse.org/distribution/11.2/repo/oss/suse/x86_64/libaugeas0-0.5.0-2.2.x86_64.rpm
rpm -Uvh http://download.opensuse.org/distribution/11.2/repo/oss/suse/x86_64/libstdc++44-4.4.1_20090817-2.3.4.x86_64.rpm
rpm -Uvh http://download.opensuse.org/distribution/11.2/repo/oss/suse/x86_64/satsolver-tools-0.14.10-1.1.1.x86_64.rpm
rpm -Uvh http://download.opensuse.org/distribution/11.2/repo/oss/suse/x86_64/zypper-1.2.8-0.1.3.x86_64.rpm

Now back to both 32-bit and 64-bit:

zypper ref
zypper dup

…And that’s all… just reboot and it should be fine.  Oh, and don’t forget to add an update repository… For example:

zypper ar http://download.opensuse.org/update/11.2 openSUSE-11.2-Update

And for pete’s sake, if you find flaws above, or a better way to do it, please let me know!  Thanks!

I run quite a few Opensuse (mostly 11.1 at the time of this writing) servers in what you might call “pseudo-production” mode.  For some of those servers, and especially for my test lab servers, I like to have them as up-to-date as possible by using some type of call to zypper in a cron job (either direct, or scripted).

And, even though I have the utmost confidence in the creators and maintainers of Opensuse, I still like to keep track of the packages that get updated, just in case some individual packages need to be reverted back to the original versions.  And of course, just running zipper up alone will not give you any tracking of those changes.

So, I wrote a handy-dandy little script (link below) that will run a comparison against what is about-to-be-updated and what-currently-exists.  The output of the script can be handled in various ways: either direct out to STDERR if running it interactively; output to a file; or if it is in a cron job, emailed out to the root user.

If there are no packages to update, you get a result that looks like this:

Number of patches found: 0
No updates this time, exiting!

If there are one or more packages to update, the output looks like this example:

Number of patches found: 2
Comparing existing packages and updates...

Existing version: package libx264-78 is not installed
Updating version: libx264-78-0.0svn20091023-0.pm.1.1


Existing version: MPlayer-1.0rc2_r29116-2.pm.29.8
Updating version: MPlayer-1.0rc2_r29796-2.pm.2.1


…and so on.  The above two packages were updated on my laptop on the day of this writing.

The script itself can be found at the link below:

zCheck-0.2.sh

…and I will update it as I make changes and improve the version, or change for the behavior of zypper, etc…

Okay, time for a few caveats:  Believe me, I know it can be better, but “better” was not my purpose here.  I just wanted a tracking history, and I tossed this together, and am posting it for you here *at your own risk*.  And I left the stuff in there to convert the output to a log file, so you can just un-comment it if you want.  If you have other errors like DNS failures and such, the script may not respond in a timely fashion.  Hmm…  I probably should have written it in Perl too, and dumped the values to an array instead of running zypper twice, but there you go.  Quick, dirty and effective.  Also, please note that the script only works with the versions of zypper that includes the XML capability; I know that this does NOT include SLES10, but I’m not sure about others.

If you have any better tweaks to it, make sure to post them, and I’ll update it as we go along…

Thanks, and I hope it helps!

While working with a customer today, we were solving some silly problems that cropped up while patching his OES2sp1 Linux servers.  Some nonsense about Mozilla dependencies on 64-bit servers (see Novell TID 7004278 for details on that). But that’s not what I’m here to discuss today…

Anyway, since SLES10sp3 came out in the past few days, a simple behavior has come to my attention.  If you run “zypper up” on a standard SLES server, for instance, it will perform the “move-to-sles10-sp3” patch and do what it sounds like it will do.  This is a good thing on a SLES server as far as I can tell so far.  Even my iFolder 3.7.2 seems to love sp3.

Also, I’ve patched a small handful of OES2sp1 servers using the command “rug up -t patch OES2-SP1-Updates SLES10-SP2-Updates“.  And (until today) by default, they did *not* perform the “move-to-sles10-sp3” as one would expect them not to, since it might break the OES2sp1 install in some ways that I don’t know or want to know.

So today, the third OES2sp1 server we were patching today suddenly prompted me with the *warning* (to which I must agree to continue) that it was going to do the migration to sp3!  Argh! I scrolled back up to see the list of patches, and it did even have the “move-to-sles10-sp3” patch in the list.  Hmm… Okay, that scared me enough.  A quick “rug lu” shows that it is still listed as an optional patch…  Hmm…

Honestly, I’m not sure what is going on here, but I wanted to make sure my regular readers/customers/friends are aware of this (if you’re an enemy of mine, go ahead and install it and tell me how it goes…), and warn that as far as I can tell, running sp3 underneath OES2sp1 is not a good (or supported) thing. Not until OES2sp2, from what I understand.

So I want to update the recommendation I’ve made here in the past.  My new preferred method of patching OESsp2-Linux servers is this:

rug up -t patch -g security -g recommended

…or optionally specify the channels too…

rug up -t patch -g security -g recommended OES2-SP1-Updates SLES10-SP2-Updates

By specifying the “security” and “recommended” types, you avoid the “optional” type, which is where the “move-to-sles10-sp3” update resides.

In the end, no matter what we did with this one server, it still tried to do the “move-to-sles10-sp3“.   So we kinda’ threw in the towel and ran the “Desktop Updater” from the GUI, which is Novell’s only other recommend method of installing updates.  And *it* did not prompt us to accept the sp3 update, just standard kernel warnings.  Phew!

If you know more about this, please share with us.  Also, I’ll update this post as discover more… Good luck out there…

Updates:  SLES10SP3 Release notes, Press Release, …

As a consultant in the Novell-related side of things, I have configured a handful of OES2 Linux servers to be Samba-aware for the end-users.  But for some reason, I always forget one particular step.  And I figured that if I wrote a post about it, it would make me remember.  Think it will work?  Only time will tell….

Anyway, the general steps to samba-enabling an OES2 user is like this:

• Create an NSS volume if you didn’t already
• Configure Universal Password for the users/containers that need to use Samba
• Configure that NSS volume for Samba if you haven’t already (shares and users)

…okay, that’s easy enough.  But the step I always forget happens only when I’m in a hurry, and am just enabling Universal Password with the defaults, just until I can go over the finer points of the policy with the customer.  Because the “defaults” of a new Universal Password will not allow samba to work;  you *must* enable one non-default thing in the policy:

• Allow admin to retrieve passwords

…or you will get an error when trying to Samba-enable the user.  The error will be something like this:

“Could not Samba enable the user for group, (windows name)-W-SambaUserGroup”

Of course, I need to clarify that I only have this problem when in a rush… I’m a nice, diligent, thorough consultant who usually designs, configures, and deploys a Universal Password Policy with a customer, in a test-bed, well in advance of deploying Samba… You believe me, don’t you?