Posts Tagged ‘GUI’

Cables connection in Israel for Linux

Thursday, May 14th, 2009

Update to 0.2. Links remain the same. At the moment I cannot host many versions (it’s mostly uncomfortable), but this might change in the future.

I have created a GUI cables installer and configurator for L2TP on Linux.

I have noticed that there is no GUI solution, so, after this has been brought up, I have done it (!!!)

I have uploaded these files here, and you are welcome to use them.

Remember – they are designed for a blank Ubuntu (currently. More distros will be supported in the future, upon request) with not much of junk installed. Also – they are designed for the simple user. Double-click and run. That’s it.

Quoting my readme file:

L2TP Cables connection in Israel (and across the world, where relevant) by Ez-Aton

This is an installer and configurator for L2TP over cables in Israel
With some luck, by running this installer, you will be able to connect
to the Internet with a dialer!

The system assumes you have little technical knowledge of Linux and you
are not expected to have any. Follow the defaults, and you should be fine.

This configuration will be cross distro in the future, meaning it will work
both on your Ubuntu, your RHEL, your Centos, Mandrake, etc. In order for me
to be able to do so, please assist by sending information on systems I am
not familiar with yet, per the appendix at the bottom.
Also, you can feel free to send me info in case the system did not work for
you (and let me know what are the differences from a default installation),
or, as always, send me money.

Visit my technical blog for updates and all kind of other technical stuff, at

OSS work is meant to be based on others work, and that I have done. I would
like to thank (and mention below) the resources for without this would not
have happened.

I hope you enjoy this dialer!


—How to use
Simply double-click on the “cables” icon on your desktop, and the system will
get you connected.
For CLI utilization: Run /usr/local/bin/cables

—Tools and resources used:
To create this package I have used the following tools and resources
xl2tpd by
xl2tpd guide for Israel Cables
ISP LNS list
My connect/disconnect scripts from

This package contents are under GNUv2 license, meaning you have full permission
to modify the contents of this package, except for the binary packages included
with it, where you are binded by their respective licenses.

—My Distro/ISP is not supported!
Well, these things happen. Over 300 distros our there, and I can’t have them all.
However – you have your own distro, right? For me to add it to this package
(assuming you don’t want to do this yourself) you will have to supply me with the
following info:
* What distro, kernel and version, and how you get the distro name
(for example – on Redhat – /etc/redhat-release. On Ubuntu – /etc/lsb-release)
* The file containing the version inforamtion (see above)
* The versions available from your repositories of xl2tpd or l2tpd for older
releases, and where you can get them
* Your ISP, your ISPs LNS names/addresses
* Your country
* All other info you think relevant

—Change log
0.2 – Added ability to enter manual LNS address. Added Orange LNS. Fixed fixroute to allow both IP and hostname without problems. Fixed cables connection script to run fixroute anyhow.
0.1 – Initial release

Download it here:

If you want the scripts and sources (not for the simple user!), you can get there here: l2tp-cables

A note about VMware-Server machine security

Saturday, November 10th, 2007

VMware allow setting a virtual machine as a private machine. By doing so, it actually adds to “/etc/vmware/vm-list-private” an additional comment, stating who is the owner of the machine. For example:

cat /etc/vmware/vm-list-private
# This file is automatically generated.
# Hand-editing this file is not recommended.
config “/vmware/Centos4-01/Centos4-01.vmx|root”
config “/vmware/Centos4-02/Centos4-02.vmx|user”

While it is very effective when used with VMware-Console (the nice GUI) – you cannot see machines which are not owned by your own user (in our example – “user”). it has nothing to do with actual permissions on the machine.

Using vmware-cmd you can control machines which are not yours, and are supposed to be private. For example, using

vmware-cmd /vmware/Centos4-01/Centos4-01.vmx stop

as the user “user”, you might be able to turn it off, overriding the obvious, or so you think, permission scheme set up by VMware through the “private guest” settings done above.

This actually has to do with the permissions and ownership on the actual vmx file. To revoke the ability to control your machines or even list them by using vmware-cmd, by an unauthorized user.

The best practice I can suggest is by setting a directory for each user (for example: /vmware for production causes, /qa for QA machines, /user1 for user1 machines, etc), and granting, recursively, permissions on this directory only to the user or group who should have the ability to control these machines. That way, even “vmware-cmd -l” which lists the available guests on an host, will not be able to view guests not owned by the invoking users.

To sum things up, private guests are all about how the GUI decides if and when to display them. eXecute permissions on the vmx files will set who can actually control a guest machine.

Installing RHEL4 on HP DL140 G3 with the embedded RAID enabled

Friday, July 6th, 2007

While DL140 G3 is quite a new piece of hardware, RHEL4, even with the later updates, is rather old.

When you decide to install RHEL4 on a DL140 G3 server, my first recommendation is this: if you decide to use the embedded SATA-II RAID controller – don’t. This is a driver-based RAID, much like the past win-modem devices. Some major parts of its operations are based on calculations done through the driver, directly on the host CPU. It has no advantages comparing to software RAID, and its major disadvantage is its immobile state – unlike software based mirror, this array cannot “migrate” to another server, unless this server is of the same type of hardware. Not sure about it, but it might also require close enough version of firmware as well.

It happened that your boss believes in win-RAID devices (despite the note above), or for some other reason you decide to use this win-RAID, here are the steps to install the system.

1. Download the latest driver disk image for RHEL4 from HP site.

2. If you have the privilage of having an NFS server, uncompress the image and put it on it, where it can be accessed through network.

3. Test that you can mount it from another server. Verify you can reach the image file. Debugging incorrect NFS issues can waste lots of time.

4. If you don’t have the privilege, I hope you have a USB floppy. Put the image on a floppy disk:

gzip -dc /path/to/compressed/image/file.gz | dd of=/dev/fd0

(/dev/fd0 assuming this is not /dev/sdX, as it tends to be with USB floppies)

5. Boot the server with the first RHEL4 CD in the drive, or with PXE, or whatever is your favorite method. In the initial boot prompt type:

linux text dd=nfs:server:/path/to/nfs/disk/disk_image.dd

This assuming that the name of the file (including its full path) is /path/to/nfs/disk/disk_image.dd. For floppy users, type dd=floppy instead.

6. RHEL will boot, loading “ahci” module (which is bad) during its startup. It will ask you to select through which network card the system is to reach the NFS server. I assume you have a working DHCP in your site.

7. As soon as you are able to use the virtual terminal (Ctrl+F2) switch to it.

8. Run the following commands:

cd /tmp
mkdir temp
cd temp
gzip -S .cgz -dc /tmp/ramfs/DD-0/modules.czf | cpio -id

cd to the modules directory, and look at the modules. Know which is the module which fits your running kernel. You can do this by using ‘uname’ command.

9. Run the following commands

rmmod ahci
rmmod adpahci
insmod KERNEL_VER/ARCH/adpahci.ko

Replace KERNEL_VER with your running(!!!) single-CPU kernel version, and replace ARCH with your architecture, either i386 or x86_64

10. Using Ctrl+F1 return to your running installer. Continue installation until the end but do not reboot the system when done.

11. When installation is done, before the reboot, return to the virtual console using Ctrl+F2.

12. Run the following commands to prepare your system for a happy reboot:

cp /tmp/temp/KERNEL_VER/ARCH/adpachi.ko /mnt/sysimage/lib/modules/KERNEL_VER/kernel/drivers/scsi/

cp /tmp/temp/KERNEL_VERsmp/ARCH/adpachi.ko /mnt/sysimage/lib/modules/KERNEL_VERsmp/kernel/drivers/scsi

Notice that we’ve copied both the single CPU (UP) and the SMP versions.

13. Edit modprobe.conf of the system-to-be and remove the line containing “alias scsi_hostadapter ahci” from the file.

14. Chroot into the system-to-be, and build your initrd:

chroot /mnt/sysimage
cd /boot
mv initrd-KERNEL_VER.img initrd-KERNEL_VER.img.orig
mv initrd-KERNEL_VERsmp.img initrd-KERNEL_VERsmp.img
mkinitrd /boot/initrd-KERNEL_VER.img KERNEL_VER
mkinitrd /boot/initrd-KERNEL_VERsmp.img KERNEL_VERsmp

If things went fine so far, you are now ready to reboot. Use Ctrl+F1 to return to the installation (anaconda) console, and reboot the system.


1. You need to download the “Driver Diskette” from HP site.

2. The latest Driver Diskette will support only Update3 and Update4 based systems. At this time, Update5 has no modules by HP yet. You can compile your own, but this is not in our scope.

3. Avoid using floppies at all cost.

4. Do not install the system in full GUI mode. In the model I have installed the VGA (Matrox device) had a bug and did not allow to reach the virtual text consoles. It disconnected the VGA. If you use GUI installation, you will be required to reboot the system into rescue mode and do steps 7 to 14 then.

5. Underlining the word smp is meant to help you not forget it. This is the more important one.

6. On the system itself, using Xorg, I was able to reach max resolution of 640×480 even with the display drivers supplied by HP. I was able to reach 1024×768 only when using 256 colors.

Installing SuSE 8 SP3 on HP DL380 G4

Thursday, January 4th, 2007

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.

Moving Exchange Data

Thursday, April 6th, 2006

Lets assume you have a method of point-in-time copy of Microsoft Exchange DB and logs, while the system is running, to an alternate server. Let’s assume, if we’re at that, that this point-in-time is consistent, and that you can mount this store (depending on using the similar directory structure, etc.), on an alternate server, and that it works correctly, aka, mounts without a problem. Scenario can be like this:

Server A: Microsoft Exchange, Storage group containing few mailbox stores, each on a different drive letter (E:, F:, G:, in our example), and the Storage Group’s logs are on a seperated drive, L:.

On Server B, we create a similar setup – Few mailbox stores, similar names, on E:, F:, G:, and we create (or move) the logs to reside on L:. We make sure this server’s patch level (or updates and versions) are similar to Server A.

We dismount the whole storage group, mark it to be overwritten by a restore, and replace the currently existing stores with our point-in-time from Server A. Great. Mounting the store, and, on a wider point of view, mounting the whole storage group’s components would be easy and painless. Our point-in-time is consistant, so it’s just like bringing up a storage group after unexpected shutdown.

Lets assume we were able to do so, we’re not finished yet. Each user’s attributes contain information pointing to the location of his/her mailbox, including the name of the store, and the name of the server. We need to change an AD attributes, per-user, for this point-in-time replication/DRP to work.

A friend of mine, Guy, has created such a script, just to solve this specific issue. It has some minor issues yet, but if you are aware of them, you can handle them quite easily. They are:

1. To run the script, make sure it is accessible via the same path on each computer running ADU&C (required only on the computers which run it). You can put it on a share, and I think it will work (haven’t tested it), or you can put it on a local directory, but make sure other computers from which you would want to run this option, have this script in the same directory (same path).

2. The script / GUI does not understand the option "Cancel", although it’s there. If you pick "Cancel", you get to actually select "0". Be aware of it.

3. The script requires resolution per OU. It means that it’s easier to move the users sharing the same mailbox store into the same OU, at least for the purpose of running the script. You could create an OU under an existing OU, and move only the users sharing the same mailbox store into it, obtaining the GPO and settings propagated to it from above.

4. There is no "uninstall" option. Don’t want it? Don’t use it. Can’t remove it unless you know what you’re doing.

I tend to believe these flaws/bugs/issues will be dealt with someday, but for the minor usage I had, it was enough, and even better.

By the way – so far, this trick cannot be used for Public Folders, as their information is hidden well too deep. Maybe someday.