Your Linux Guy .com

To help someone (like me, for instance) remotely diagnose your Suse system, sometimes you need to send him or her diagnostic info from that system.  Fortunately, Suse has a toolset called “supportutils” to do just that.  This article outlines one of my preferred ways of generating and sending such info.  Note that the examples in this article are targeted toward my existing customers, but you can obviously change the examples to suit.  Or, you can *become* a customer… 

First, su to root, and check to see if the support utilities and sysstat package are installed:

zypper se sysstat supportutils 

…if the result for each has an “i” (for “installed”) at the far left of the package, it is already installed.  Otherwise, if the package(s) are not already installed, run this to install the sysstat package and the support utilities included with your Suse distro:

zypper in sysstat supportutils

Or, if you wish to run the latest version of the supportutils package (see “comment” below about versions), run this to install/upgrade to the latest version at the time of this writing:

rpm -Uvh http://download.opensuse.org/repositories/Novell:/NTS/SLE_10/noarch/supportutils-1.20-1.1.noarch.rpm

(Please see the Supportutils project page at http://en.opensuse.org/Supportutils for the latest info and versions.)

COMMENT:  Unfortunately, I have discovered that the info collection part of some modules seems to be broken on some versions; I’m not sure why.  You’ll know they need to be skipped if you run the tool and it hangs for a long time.  I’ve seen the DNS module hang on most systems with the older package, the SYSFS module hang on Opensuse with the latest version, the NSS modules hang on OES servers, and so forth.  Personally, and take this for what it’s worth, I like the distro-provided supportutils package on OpenSuse, and the latest download-able on available for SLES10 and/or OES servers… all with the caveats, of course…

So, to get around the sticking/hanging problem, we need to modify the configuration file to skip the info collection for those modules that get stuck  (of course, it is also possible that you want to modify the config file to exclude certain things for other reasons, as well).  For this example, I disable the DNS info collection (which has since been repaired in newer versions).  You can do it interactively with vi or gedit like this:

vi /etc/supportconfig.conf

…(or via gui, gedit /etc/supportconfig.conf) and change this line:

OPTION_DNS=1

…to…

OPTION_DNS=0

…or do it non-interactively with this example command set:

mv /etc/supportconfig.conf /etc/supportconfig.conf.bak
sed s/OPTION_DNS\=1/OPTION_DNS\=0/ /etc/supportconfig.conf.bak > /etc/supportconfig.conf

Now back to the program; whether you upgraded, modified the config file, or not….

Next, create the output with this command:

supportconfig

When completed, it give you a nice info summary.  One of the first lines in the summary is the resulting tar ball file size.  If it is reasonably small, like under 10MB, feel free to send it to me via email it to me this way (if it is larger than 10MB, I can provide an alternate method of delivery):

echo "See attached." | mailx -a /var/log/nts*`date +%y%m%d_%H`*.tbz -s "Support Config file from $HOSTNAME" jpavlov@yourLinuxGuy.com

…Note that the above command will send all of the result files that were generated in the current hour; you can take off the “%H” if the file you wish to send was generated in a different clock hour.

If you’re curious, when I get it, I download from my email and unzip it in a temp directory for review:

cd /tmp/support
tar -jxvf nts_lt1101010_100106_1010.tbz

And that’s it!  I hope it helps.  And, I hope I can help you…

This basic (re-worded) question came in from Jeff: “Why won’t my remote filesystem mount unmount when I try the umount command?”

It’s very true:  If you try to umount (unmount) a filesystem that is currently being accessed, it will not let you do it.  And it will tell you something like, “umount: /media/ncp: device is busy“.  What causes this?  Well, it’s likely to be one of two things:

1. You have (or someone else has) cd‘d onto the remote filesystem and are currently at or below the mount point root
2. You are running an application that has a file open on that mount point

To mitigate item #1 above (if you are the guilty party, not someone else), just cd to the filesystem root (like cd /), or some other place you know is not on the mount point (like cd /tmp).  Then you can run your umount command.

Solving item #2 above is perhaps a tad more tricky.  Of course, if you have a suspicion or direct knowledge of the guilty app, then you can just stop it.  Sometimes doing this:

ps -ef | grep
…or…
ps aux |grep

…will show the process and any files it accessed by the startup command.

Either way, my favorite way to check for both item #1 and #2 above is to use lsof.  This utility will list *every* file that the system has a hold on.  And this is essential because after all, we know that Linux is nothing but a bunch of files, right?

So here’s what I like to do, for example:

lsof| grep "/media"

… this will show you if anyone or anything is currently sitting on the mountpoint (of course, change your mountpoint to suit, be it /media, /mnt, /export, whatever).  If it shows anything, you can see who or what is at fault, and tell them to get off it, or kill them (I mean the app, jeez…).  If you really need to see the headers of the columns, you can do a double-run for cosmetic purposes that will run once for just the header, then again to grab your detail, like this:

lsof |head -1;lsof| grep "/media"

Another way is to use the fuser command, referencing your mount point. Here’s my favorite set of flags in an example:

fuser -uv /media/ncp

I hope that helps!

Recently I came out of the 1990’s, and moved to an IBM laptop that does not have a serial port… Gasp!

Of course, this is not a big deal to alot of people, but I’m a server guy.  I do terminal sessions to Sun/Solaris servers and Cisco routers and such;  I really can’t live without a serial port.  So I basically had 2 options:

1. Go back to my old latop (nope, no way, nahgahdah)
2. Get a USB attached serial port

…so after reading a ton of reviews at NewEgg.com, I finally settled on the CABLES UNLIMITED USB-2920 USB 2.0 to Serial DB9 Adapter.  At the time I bought it, it was on sale and had a shipping special.  But at the time of this writing it is $16.99.  …Still not bad, really.

First, Windows

As it happens, when I first bought it, I connected it to my laptop, and I fired up a Windows XP guest in VMWare Server 2 on my Opensuse 11.2, and “virtually” connected the USB to the XP guest (can’t do *that* in ESX… nyah, nyah).  The driver installation in Windows was a little weird,  since the driver installation was a little language-challenged…  But if you know what you’re doing, you can get it done.  Once it was all set up in Windows, it was easy to use in Hyper Terminal and Putty, and it really worked perfectly.

Then, Linux

A few days later, I needed to do a serial connection again.  This time I didn’t feel like firing up my VM guest, so decided to stop playing around, and configure it natively in Linux for use in minicom.  Here’s where it gets good…  It is sooooo easy to setup in Opensuse, and I hope/assume it is nearly as easy in other distros, though I’ve not tested it.  Here’s basically what I did:

Step 1:  Plug into adapter into USB port

Step 2:  Launch minicom -s (to enter configuration)

Step 3:  Configure the port as /dev/ttyUSB0  (that’s a zero, though it could be a 1 on yours if you have multiple), and save as “dfl” (default)

Step 4:  Enjoy!

I hope this helps…

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!