Some of you might take it lightly, some of you might take it seriously, and encrypt your wireless network, block the network to specific MAC addresses, etc. This guy had one special treat for his neighbors. Maybe I should try that too…
Archive for January, 2007
To be able to fax a text file containing Unicode (especially non-English characters), a suggestion can be found in this mailing-list post. I could not use it, though, because my Unicode text had ASCII-art-tables, and the printing process forced using variable font. I was unable to convert the text to an encoding (using iconv or uniconv) fit for a fixed-size font I’ve had available.
I’ve managed to print the text to PDF finally, which then I was able to fax as I pleased. Unfortunately, I am unable to state the tools used for this task. Sorry.
Per the last post in this thread, I have created a startup script to an Oracle setup I’ve had.
The script is rather simple – you “su –” to the Oracle user, and you just start the DB. Same goes for shutting it down. I have tested it and it worked well.
Due to the customer’s demands, we’ve relocated the DB data to an NFS on NetApp. Afterwards, reboots didn’t go quite will. It seemed that the DB never went down correctly, and that we’ve managed, somehow, to umount the NFS volumes without shutting it down.
After a short investigation, it was revealed that /etc/rc.d/rc, which controls the startup and shutdown of services on a system, checks to verify that there is a lock file with the same name as the startup service. In our case – we should have created an empty file in /var/lock/subsys/ named dbora during the startup of our dbora script.
When changing the script to do it (and to remove the file during shutdown), things started working correcly.
Installing older Linux systems on new hardware is always fun. SuSE 8 especially might be tricky, due to several assumptions during install:
1. The install kernel is the Single CPU version. However, on an SMP system, the Single CPU kernel would not be actually installed.
2. HP assume you have a floppy with your server. You probably don’t.
The procedure went like this:
1. Download from HP site the required drivers RPM.
2. Extract the RPM file using rpm2cpio (for example: "rpm2cpio drivers.rpm | cpio -id" ). Copy the drivers, per the kernel versions which will be used to a Disk-on-Key. Also, for later use, put the RPM file on the Disk-on-Key.
3. Boot the server with the SP3 CD. It will ask for the first SuSE CD. Insert it, and it will claim it cannot detect disks.
4. Insert USB Disk-on-Key to USB slot. Go to command shell (Ctrl+Alt+F2).
5. run "modprobe usb-storage"
6. Using "dmesg" verify the USB device is detected and attached to a SCSI device. Mount it to some temporary location.
7. Insert the cciss.o module manually, per the correct kernel version. When done, umount the USB volume and disconnect it.
8. Using "Ctrl+Alt+F6" go back to the installation GUI. Select partitioning, and using the manual (advanced) interface, rescan the disks. You will see your CCISS disks.
9. Install the system. When done, you will have to reboot it back to stage 6.
10. Insert the cciss.o module manually, per the correct kernel version.
11. Mount your system volume to a temporary location.
12. Copy the drivers RPM to the /root of the system volume.
13. Chroot into the mounted system volume.
14. edit /etc/sysconfig/kernel and add the module "cciss" to the modules list in it.
15. Install the drivers RPM.
16. Exit from the chrooted shell, and restart the server. Eject the CD when done.
Now you should have a running SuSE 8 system on an HP DL380 G4.
I assume such stages can be performed on a G5 server as well, however, with HP not supplying CCISS drivers on their site for SuSE 8, the only option seems valid (and I didn’t try it yet) is to compile the CCISS module based on sources obtained from the CCISS SF site on another SuSE 8 server, and using them in a way similar to the one described above.