Stephen C's questions

I'm trying to fix a problem in a Chef recipe for installing / configuring ClamAV which is caused by the recipe using the wrong default user/group name for the clam service account on some platforms.

It seems that:

• On CentOS 6, the service account is "clam"
• On Fedora 19, the service account is "clamupdate"
• On Ubuntu 12.04, the service account is "clamav".

Based on this, I'm guessing that the pattern can be generalized (in Chef terms) to:

• Debian family - "clamav"
• RHEL family - "clam"
• Fedora family - "clamupdate"

Questions:

1. Have I over-simplified this?

2. Does anyone know of any examples that contradict this? (Lets assume that we are talking about the "recommended" RPMs / DEBs for the respective platforms ...)

I'm trying to set up Chef-managed accounts for a group of machines with the following characteristics:

• If there is no local account, login is blocked.
• If there is a local account with SSH keys, use those for authentication is possible.
• If there is a local account that has a local password, that password is used for authentication.
• If there is a local account with no local password, Kerberos is used.

I've got that much working.

But the last thing I want to be able to do is to disable login on the account by locally locking the password (e.g. using usermod -L). The problem is that when the local password is locked, PAM is falling back to Kerberos ... and allowing access.

Is there a way to configure PAM so that if a local password exists but it is locked that it won't try Kerberos?

The best I can think of so far is to lock the account by clobbering the local password with something unguessable. But that is a bit crude, and doesn't play well if someone does not "follow the procedure" ...

Is it good practice to version control the nodes and roles when using chef? If so, what is a good way to do it?

It looks likes one should be able to take a tree of JSON files created using chef_server_backup.rb and simply check it into VC. Are there better alternatives?

Update

It turns out that checking in the JSON produced by chef_server_backup.rb is not a good solution. The problem is that the JSON produced by the script is not stable. Each time the hashes come out in a different order and the resulting files are totally different to the previous versions ... even though they means the same thing when parsed as JSON. I would be better of just saving compress tarballs.

(But if I could canonicalize the JSON files by ordering the attributes ... )

Recently we ran into a problem where one of our Linux-based virtual machines was really slow due to a chronic shortage of "entropy".

I'm wondering if Windows virtual machines would suffer from the same problem. (A Google search gave me no relevant hits, but I could be using the wrong search terms.)

I have a use-case where a chef recipe needs to use 'remote_file' to fetch a file on a virtual, and the fetch needs to be do through an HTTP proxy. This is not working because chef-client doesn't use the system proxy settings ... it gets its proxy settings from the /etc/chef/chef-client.rb

So how do I get proxy settings (or settings in general) into the chef-client.rb file on a client?

Ideally, I'd like it to happen at client bootstrap time, but I can't see how to do that short of hacking the code.

The other possibility is that I could create a recipe that updates the chef-client.rb file. But that strikes me as a bit dangerous. And it means that you need to run chef-client twice before it works, assuming that the missing proxy setting in the first run causes the run to ultimately fail.

Any ideas on how to fix this?

We've got a CentOS server running a cluster of virtuals. Occasionally the cluster's internal network drops out for a minute or so ... and then comes back. The problem is somehow related to the actual network traffic, but it is not a simple load issue. (The system is generally lightly loaded, and the problem occurs irrespective of actual load.)

The setup:

• CentOS 5.6 on Dom0, various CentOS on the DomU's
• Hardware - a Dell R710 with a BroadCom NextXpress 2 NIC (sigh)
  • using the latest drivers for the NIC from BroadCom
• Xen configured to use network-bridge and vif-bridge
• Some iptable tweaks to route an unrelated port to one of the virtuals.

The system has one externally visible IP address, and Dom0 runs an Apache httpd configured with a number of virtual hosts each of which reverse proxies to web servers running on the virtuals. (The virtuals have to be NAT'ed, primarily because we don't have enough allocated public IP addresses.)

The symptoms:

• Works fine most of the time.
• When someone tries to UPLOAD a large file to one virtuals, the internal network drops out ... for all virtuals:
  • The Dom0 httpd sees a network timeout talking to the backend server on the virtual and reports a 502.
  • A previously established ssh connection from Dom0 to any of the DomU's freezes.
  • Our monitoring shows ping failures for traffic between virtuals.
  • The Xen consoles to the DomU's do not freeze.
  • No log messages in any log files that I can see, on either Dom0 or the DomU's ... apart from the Dom0 httpd logs.
  • After a minute or so, the problem clears by itself.

This is 100% reproducible.

What we've tried:

• Downloading, building and installing the latest BNX2 driver on Dom0
• Turning off MSI on the NIC - adding "options bnx2 disable_msi=1" to /etc/modprobe.conf
• Turning off tcp segmentation offload - "ethtool -K eth0 tso off".
• Sacrificing a black rooster at midnight.

I've exhausted all my options apart from switching to KVM ... or slaughtering more roosters.

Any suggestions?