Tim Post's questions

I'm looking for a gigabit Ethernet adapter with a TCP offload engine that will work nicely with a modern Linux kernel. Due to the way patches and updates are handled, I really need one that has an open (blob-less) driver.

I'm beginning to think such a thing might not exist. I'm hoping that I'm just missing a lesser known manufacturer that I could try. I'd rather put up with a relatively quirky card than have to deal with the issues surrounding closed source TOE drivers in Linux.

I'm aware of the venerable Broadcom and Intel team cards, but I don't want to buy yet another piece of hardware that requires dealing with non-free firmware or driver blobs. I'm so close to getting rid of anything that won't work without them, I'd hate to introduce something else.

I'd also appreciate any 'home brew' experiences, if they relate to this question.

I'm making some init scripts to start some system services that require other services to have started in order to start successfully. For instance, one service requires that xenstored be running before it can start.

If I understand correctly, LSB init scripts have the following directives:

# Required-Start:
# Should-Start:
# Required-Stop:
# Should-Stop:

My question is, would it be sufficient to simply put xenstored after Required-Start: and what is the difference between Required and Should? Additionally, Does Debian 5 honor these directives?

What I have:

• Workstations running Ubuntu Jaunty mounting /home on a remote NFS server. User accounts are still created locally on each individual workstation.
• Workstations running Windows XP / Vista
• NFS server (as noted above)
• Windows 2008 server
• All machines share a single private network (LAN).

What I need to accomplish:

A single, intuitive (GUI driven) place for an office administrator to create user accounts. This should let anyone login to their (linux or windows) workstation, then fire up remote desktop and use the same login to the Windows 2008 server, from any machine on the network.

I have read so much on samba, LDAP vs AD, etc and now I'm even more confused than I was before I began researching the problem. Ideally, Linux and Windows users should be able to get to their local files once logged into the Win2008 server. I am a programmer, not an interoperability guru and I'm completely lost on where to even start trying to accomplish this, plus I've run out of things to Google.

How would you do this? Is it even possible?

Edit

MacOS is not a consideration. Dealing with personal laptops ends at assigning them an IP when they plug in. I'm concerned only with Linux / Windows workstations that exist on an entirely different subnet.

I am writing a program that needs to be able to detect the presence of various web hosting control panels. I don't use Plesk, or have access to a server running Plesk, so I am unable to ascertain what file or directory I could test for to reliably conclude that the system is running Plesk.

What file or directory indicates "Yes, this has Plesk installed" that is unlikely to ever change in the future, but would be present on all versions of Plesk out in the wild?

Thanks in advance :)

I'm running Trixbox CE (v2.6.2.3) and I need to make a full system backup of all configurations, recordings, databases, etc in a manner that can be easily restored on a brand new installation of the same version of Trixbox CE.

I started to write something myself using rsync, however I feel like I'm probably missing some things and needlessly copying other things.

What are my options? The back up module that normally works with FreePBX is not working with the stable version of Trixbox CE.

I'm using AoE (ATA Over Ethernet) on a Linux NAS with bonded gigabit nics. I'm curious as to which bonding mode is most appropriate for use with AoE? (balance-rr, balance-xor, 802.3, etc)

I'm using good procurve switches, I have tweaked sysctl so that kernel rx/tx buffers are appropriate for jumbo frames, I just want to be sure to select the appropriate bonding type. I am looking for optimal performance and failover (or, well, why you'd bond in the first place).