OSCAR…not working quite yet

Yesterday, I used the start_over script in OSCAR to…start over. I did the log out and back in it said, and I proceeded to reinstall and reconfigure OSCAR. This time, though, I opted to use a mirror for the rpms it needed, and I then proceeded to build the client image. After a very long time, an error was reported, it told me to check a log file which is really a script. Meanwhile, the client computers don’t even boot past the bios with the hard drives in. Today, we will have to somehow format the hard drives and start over with OSCAR.

Getting OSCAR ready

Our next task is to set up a small cluster, a “supercomputer”. Right now, there are two software based solutions we are going to look at, both involving Linux. The first one which is supposed to be easier to set up, and very well documented, is OSCAR. I found the instructions to setting it up here. We decided on using Fedora 5 as our OS base, since it was fully supported, so we downloaded it and installed it on the Dell server. Once this was complete, I began setting up OSCAR. Once a lot of the tedious set up was over, I attempted to run the set up script like it said in the documentation. However, the name in the documentation was wrong as I soon discovered, I did find it, though. A few more errors popped up, however, I just looked at the log and made the necessary changes. Once this was complete, the gui based setup came up, and I proceeded to install the server package, and next was the image for the client nodes. Setting it up though, required some more legwork. I had originally set it up so the necessary rpms for the client nodes would be downloaded from a mirror. I thought this would be too slow, so I got the rpms off the cds for Fedora. However, I was getting errors that dependencies, other packages that packages need, were missing. Therefore, we tried a combination of both cds and mirror, and after a long wait, it said completed successfully. Next was the deployment of the images. After setting it so it would get the image off the server, I turned on three clients. The first one got errors, which I believe occurred because the first one has to be the server. The other two seemed to have installed. However, those two no longer can boot from the hard disk, in fact, they don’t boot past the HP screen unless the hard drive is removed. Brian removed the CMOS battery, and I put them back and tried the computers again this morning, however, to no avail. I was waiting to post some good news in our supercomputing ventures, but here is where we’re at.

Managed Switches

We decided today after testing the mini cds and the applications to figure out the managed switches. Mr. Birchall had given us an SMC EZ1024DT–an “EZ” unmanaged switch, an SMC Tigerswitch which was managed and we had an HP ProCurve 224M. For the Edubuntu server project, we decided to use the EZ switch and experiment with the managed switches a bit later. Today, we started with the HP switch since we could actually find documentation on HP’s site. We connected it directly to the server through a serial port, and fixed the ip address and the gateway, so we could also use the web interface–previously this was not working. Once we tested to see if everything was working, we configured the SMC Tigerswitch the same way by connecting it via serial. We are able to use all our switches now, and hopefully we may be able to play around with a more advanced switch later.

Applications to Send Home on Mini-CDs

Mr. Birchall wanted us to test some applications to send home, mainly the FirstClass client software so students can access school email. We would place these applications on a mini cd-r. Therefore, we also had to test the integrity of the mini cd-rs. For applications, we decided on adding Firefox and also Pidgin for Windows, and just Firefox for Macs. We like Firefox as an internet browser and we added Pidgin because it is an open source alternative to AOL Instant Messenger. We burned many mini cd-rs with the software and tried them in our different cd readers. We did some more testing by scratching them and exposing them to everyday wear and tear. We concluded the integrity of the discs were fine; we had no problem burning and reading the discs, and the mini cds couldn’t take any less abuse than regular cds.

Edubuntu 7.04 Server Edition…our server operating system edition of choice

    When we tested the desktop versions of Ubuntu, we decided upon Dapper (6.06.1) for its long term support, and the fact that Feisty (7.04) was not installing due to some bugs.  We settled on Ubuntu at the end because we felt Edubuntu was Ubuntu with some childlike icons. However, it was a different story with the server. We switched to Edubuntu when we began, because it had ltsp support built in–all I had to do was install it and a thin client booted up from the start. In addition, it was Ubuntu, which we already loved, and we just changed the theme and icons. However, ltsp in Edubuntu Dapper did not support local devices such as flash drives, and an ltsp developer highly recommended we go to Feisty for its better ltsp features. We did, and we have not had the problems we encountered when using the desktop editions.

Even while we were using the older version, we continued to test software and other settings to emulate a real environment. I used my old list of software and plugins, configured all of them and made sure they worked on the thin clients. A change I made was instead of using realplayer, I found that through synaptics I could get the Fluendo mp3 codec, so music and audio would work using Ubuntu’s default Rhythmbox music player. I had also scrapped Audacity due to the other plugins it was coming with. In addition, a small change I made was the stopping of the bluetooth service at startup. The only other software type changes I made were documented in my previous blog entries.

Regarding user permissions, Ubuntu is already good about limiting people. Even if a limited user knew the root or administrator password, they would not be able to install software or make changes through their own account. Of course they probably be able to login to our account if they knew that much…but they would never find out any of that. In addition, we edited the menus so it would be difficult to see anything important, using the Alacarte menu editor that comes with Ubuntu. One last thing we are going to check is if we can remove Bittorrent and other packages we don’t want that come with Ubuntu completely, although it says it is going to remove the entire desktop. From my research, it won’t be a problem, and if that is not a plausible method, Bittorrent has been disabled since we edited some settings in gconf-editor. In addition a great tool we should use if we deployed this in our environment was sabayon, which I documented earlier, that made configuring users extremely simple, along with our shell script.

Other than the testing to see if some programs that are “locked to ubuntu-desktop”  can be removed (once our backup finishes), we hope to have completely exhausted our research on Ubuntu server editions.

Login Problem With Sabayon-Fixed

We discovered this morning that we had problems logging in at the thin clients with our administrator accounts. I knew that not much had changed other than the fact we updated our computer and install sabayon to customize the user profiles. I was pretty sure the problem came from the new software, so I googled it and found out that it was indeed sabayon’s fault. Only users under the sabayon “group” would be able to log in. Meaning, unless they were added under the group manually, only the users under a sabayon profile like our student profile would be able to log in. The fix was easy-we selected the “add every user” option for student so it would be easier if we had to make hundreds of students/faculty. However, we also made a blank administrator profile, and added ourselves to that one, and still maintained our privileges.

Configuring Many Users In Edubuntu / Ubuntu

A big concern for us was that we would have to add hundreds of users in a real environment. We have a server with a few test users set up and thin clients which work, but we would have to set up hundreds of users with the same settings including the theme (a normal one, not the elementary school one), permissions, menus (so you cannot see administrative functions), and other settings edited in gconf-editor that for instance prevent locking of the screen. After googling for a long time and asking on the Edubuntu and Ubuntu irc channels, someone finally suggested I try Sabayon, which configures user profiles. It is a really great tool; you make a profile, I called ours student, and when you select edit you get a small window which simulates a real desktop. So whatever changes I made were saved and applied to any user I selected. After this was working, there was still the task of adding many users that we would be able to apply the student profile to. I knew that we needed a shell script, so I asked around again and I found the exact syntax. We would still need to enter the password for each person, but that could be done. The syntax goes something like this.