sagi's questions

Here's the situation. I would like to connect my Linux servers to a single network using dual link for fault tolerance and load balancing reasons. The servers have 2 or more 1-gig NICs and I plan to connect each of them to a different switch that reside in a single stack (i.e. a single virtual switch). All switches are Juniper EX4200 or EX4500.

I know I can use any of the Linux bonding modes and I wonder what is the best one. Historically I used the active-backup mode because some servers were connecting to non-stacked switches but now we have a new and consistent network and I would like to take use a bonding mode that offers load balancing in addition to fault tolerance.

I thought the best mode to use is 802.3ad (LACP) because that's the standard being used on all network equipment, but as it turns out the moment I configure a set of ports as an LACP channel on the switch side the connection breaks until I also configure the server side properly. This makes our system administration tasks much harder because before installing a new server we must remove the LACP configuration on the switch (because things like PXE boot and network installation do not work on LACP ports), and after the installation we need must change the switch settings again but only after the server was configured to use LACP, or the connection will die.

Other bonding modes such as balance-alb do not require any special configuration on the switch side while on paper provide the same advantages.

Is there any reason to choose 802.3ad instead of balance-alb?

We have bought a few 30amp 208v PDUs that only have 9 receptacles. The servers we are connecting to those PDUs will not use the full 30amps (at 80%, or actually 40% since we use redundant power) so we need to find a way to connect more than 9 servers to the same 9 receptacles so we'll be not wasting capacity that we pay for.

I thought about using a Y split cable like this one: http://www.cablesandkits.com/power-cord-c14-c13-splitter-cable-awg-p-515.html

That will let me connect two servers to a single receptacle.

Each of the individual receptacles can provide 12 amps of power and individual servers are unlikely to consume more than 3 amps at maximal load so it should provide sufficient power.

The question is if there is any other reason why this may be a bad idea and if there is any other solution other than buying PDUs with more receptacles (which I don't want to do because I must use horizontal PDU on these racks and ones with more receptacles consume more U space).

I have a Dell PE1950 running the latest OpenSolaris, connected to a Dell MD1000 enclosure with 15 disks in it. I am not using PERC to control the disks, instead I use a simple SAS 5/E (LSISAS1068) controller that exposes the raw disks so we can use ZFS RAID instead of hardware RAID.

It all works very well, but I have one worry about the time when we need to replace one of the disks for any reason. When I used PERC, it had the capability of turning the error led on the disk if something went bad, and also gave me a way to manually blink the led should I want to physically locate it for any reason.

However, now when I use the plain SAS connection it looks like these capabilities are inaccessible, and the only way to identify the disk is by guessing what it is from the device number (which I find very risky), or shutting down the whole system, pulling the disks one by one and comparing the serial#.

Both options are, of course, not acceptable. I would like to know if there is any way that I could manually operate the LEDs on Solaris. I have searched a lot and found that on Sun servers this can be done using the cfgadm tool, but when I tried to run the same commands on my server it failed, saying the hardware specific feature is unavailable.

I also tried using the LSIUtil command, but it doesn't seem like it supports this functionality either.

Is there any way I could visually identify the disks?

We have bought several new Dell PowerEdge R410 with a iDRAC6 Enterprise card, which is supposed to give us full remote access control over the machine, including virtual console and virtual media.

Overall, it works as expected. I can use the virtual console and also the virtual media to control the machine remotely. However, when I reboot the machine the DRAC IP becomes unavailable for over 30 seconds (i.e. not responding to any network activity such as ping or HTTP requests). By the time it finally becomes available again, the server is often past the boot sequence which means I cannot enter the BIOS, or boot from virtual media.

I managed to solve this by using the cold-power-switch option after which it takes more time to the machine to fully reboot and after a few tries if I act very fast I manage to catch it before the boot sequence is over. But it doesn't look right, from my understanding the DRAC mechanism is separate and should not be affected by the server reboot. Why does it reset the connection? Is there any way to prevent this?

I have a few servers running CentOS 5.3, and am trying to get 2 NFS mount-points to mount automatically on boot. I added 2 lines similar to the following to fstab:

server1:/path1                /path1           nfs     soft            0 0
server2:/path2                /path2           nfs     soft            0 0

When I run 'mount -a' manually, the mount points are properly mounted as expected. However, when I reboot the machine, only /path2 is mounted. For /path1 I get the following error:

mount: can't get address for server1

It obviously looks like a DNS issue, but the record is properly configured in all the DNS servers and is mounted properly if I re-try the mount after the reboot is completed. I could properly fix this by using IP address instead of hostnames in /etc/fstab or adding server1 to /etc/hosts but I would rather not do that.

What might be the reason for failing to resolve this specific address during boot time? Why the problem is only with the 1st mount point and the 2nd is properly mounted despite having identical configuration?

I have a bunch of servers running CentOS 5.3 32-bit. They were all installed at about the same time using the same installation method (either CD or net install).

I have recently noticed a problem with one of the hosts, which reports errors such as the following when attempting to verify an RPM package:

[sagi@server3 ~]$ rpm -qV coreutils 2>&1| grep mkdir
prelink: /bin/mkdir: at least one of file's dependencies has changed since prelinking
S.?.....    /bin/mkdir
[sagi@server3 ~]$

The prelink message is the one that first caught my attention. It appears often when trying to do any kind of RPM related operations. But also, the verify command reports that there is a size mismatch for the mkdir package, which I don't understand.

I tried to run the same command on some of the other servers and none of the has the same problem. The size of /bin/mkdir and the version of coreutils is identical on the problematic server and all the other hosts, e.g.:

[sagi@server3 ~]$ rpm -q coreutils
coreutils-5.97-19.el5
[sagi@server3 ~]$ ls -l /bin/mkdir
-rwxr-xr-x 1 root root 29852 Jan 21  2009 /bin/mkdir
[sagi@server3 ~]$

[sagi@server4 ~]$ rpm -q coreutils
coreutils-5.97-19.el5
[sagi@server4 ~]$ ls -l /bin/mkdir
-rwxr-xr-x 1 root root 29852 Jan 21  2009 /bin/mkdir
[sagi@server4 ~]$

But the MD5 of /bin/mkdir is different on each host:

server1  f62677e910d9a3fc3605be5e3e59bb4f  /bin/mkdir
server2  7678ac9fdf01a80e4dc45cb8a6929e2b  /bin/mkdir
server3  4fe934b9ebd16ba773cf347ebf803225  /bin/mkdir
server4  24800902f32af19879ed5fda0f3ea9d0  /bin/mkdir
server5  a0a02615022c7f607709792a5ceaad0e  /bin/mkdir

And so on. /bin/mkdir is just a sample, I encountered the same issue with every single utility that I checked.

Therefore, I have two questions: 1. Why would the MD5 of the exact same file be different across different machines? 2. What may be the cause of the prelink message mentioned above?

Update: I managed to get rid of the prelink errors by manually running the /etc/cron.daily/prelink script. I still don't understand what is the cause of the different MD5 though.

I know it is possible to assign multiple IP addresses to the same NIC as long as they are on the same sub-net (e.g. server A can be assigned both 192.168.1.1 and 192.168.1.2).

However, is it possible to assign multiple IP addresses that are a different sub-net to the same NIC? The server will be connected to a switch with multiple VLANs configured on it, e.g. 192.168.1.1/24 and 10.0.0.0/24. I want the server to be both 192.168.1.1 and 10.0.0.1.

The reason I want to do this is that we currently have an internal network on 192.168.1.0/24 and we want to add additional private network for management needs: e.g. putting Dell DRAC devices on this network. I want to know if it is possible to do this without adding more cables and more switch ports.

We currently have a private IP subnet using the 192.168.1.0/24 range. We are running out of IP addresses and would like to extend this subnet, to something like 192.168.0.0/21.

Is it possible to do such change without significant downtime? if we first change the VLAN configuration on our switch to use the new netmask, will all the connected machines with the old configuration immediately break until we change their configuration? or will they continue to work as before but will only see the previous subnet, and not hosts with IPs on the extended subnet, and then we could gradually change the netmask on each host with no downtime except what's required for a local NIC restart?

I am trying to find a way to quickly restart Apache to apply configuration changes. The goal is to:

1. Restart without distributing currently processed requests
2. Do this as atomically as possible, i.e. the new configuration must be applied on all new requests received from the restart time on, no new requests should by handled by the old version.

Apache has a graceful restart command that satisfies the first goal, the restart command is immediate and existing requests are not affected. However, the restart is not atomic. If there are existing connections to the server in Keep-Alive state, then all the following requests that they send are handled by old processes with the old configuration.

In my case, the Apache server is sitting behind a load balancer which may send hundreds of requests over a single connection. So after the restart, it takes many long minutes until the new configuration is applied to all new requests.

Is there any way to fix this, e.g. make Apache close any existing Keep-Alive connection to an old process after it finishes serving the current request?

I am running CentOS 5.3 as a VirtualBox 3.0.0 guest running on Windows XP.

The Windows host CPU usage is constantly at 50% although the CentOS guest is completely idle (i.e. 0.00 load average).

I know this is a common problem related to the 1000Hz frequency that the CentOS kernel runs at, and previously a special kernel-vm packages were released to resolve the issue. However, these packages are out of date and the README says that they are not not necessary as of CentOS 5.3. I found out that there is supposedly a kernel parameter divider=10 that reduces the frequency to 100Hz with the standard kernel but it doesn't seem to have any effect when running inside VirtualBox.

Is there any way to resolve the issue without resorting to a custom kernel?