asciiphil's questions

I have a ZFS filesystem (ZFS version 0.8.5) on Linux (kernel 3.10.0) for which I'd like to restrict the total path length on nested directories. I'm not sure if there's a way to do that, though.

My backup software appears to have some limit just short of 4096 characters. To work around that, I'd like to have something in place where attempts to create a directory (or filename) that would result in a path length of more than 4000 characters will fail. (If this is a per-filesystem setting, the limit would have to be lower, since I'll have to take the length of the filesystem mountpoint's path into account.)

Is there a way to do that, either with the Linux kernel, ZFS module parameters, or ZFS filesystem properties? (Or some other avenue?)

Note that Linux's PATH_MAX value is not a solution here. PATH_MAX on my system is 4096, but I can easily create directories whose full paths exceed that limit. e.g.:

mkdir -p $(python -c 'print("/".join(["n" * 255] * 512))')

That will, without error, create a directory with 131071 characters from the current directory.

I want to have a resource (or something) that I can use in several Puppet classes to cause a different resource to receive a list of the values defined in the source classes. I'm not sure how best to go about this.

More concretely:

I have a resource that creates a Nagios host definition. Each host definition includes one or more hostgroups.[0] I would like to define things generically so that the hostgroups for a host are determined dynamically based on the classes assigned to the Puppet node.

For example, let's say I have a node:

node www.example.com {
  include common_definitions
  include web_server
  include ftp_server
}

I would like to have something in the web_server and ftp_server classes that add relevant hostgroups to the Nagios definitions. Perhaps something like this:

class web_server {
  ...
  nagios::hostgroup { 'web-servers': hostname => $facts['hostname'] }
}
class ftp_server {
  ...
  nagios::hostgroup { 'ftp-servers': hostname => $facts['hostname'] }
}

Then the Nagios host definition would have something like this:

class nagios {
  $hostgroups = collect_exported_hostgroups_for($facts['hostname'])
  $hostgroup_string = join($hostgroups, ',')
  nagios:host_definition { $facts['hostname']:
    hostgroups => $hostgroup_string,
    ...
  }
}

The key fact is that the nagios class doesn't know anything about what hostgroups to use until Puppet processes all of the node's other classes. This drives the process from the classes assigned to the node.

How can I do this?

[0] Technically, a host definition includes zero or more hostgroups, but my definitions will always have at least one hostgroup.

I have a system that suffered from ever-increasing memory usage until it hit the point where it was hitting swap even for mundane things and consequently becoming pretty unresponsive. The culprit appears to have been kernel-allocated memory, but I'm having difficulty figuring out what exactly was going on in the kernel.

How can I tell which kernel threads/modules/whatever are responsible for particular chunks of kernel memory usage?

Here's a graph of the system's memory usage over time:

The slab_unrecl value, which grows over time, corresponds to the SUnreclaim field in /proc/meminfo.

When I ran slabtop towards the end of that graph and sorted it by cache size, here's what it showed me:

 Active / Total Objects (% used)    : 15451251 / 15530002 (99.5%)
 Active / Total Slabs (% used)      : 399651 / 399651 (100.0%)
 Active / Total Caches (% used)     : 85 / 113 (75.2%)
 Active / Total Size (% used)       : 2394126.21K / 2416458.60K (99.1%)
 Minimum / Average / Maximum Object : 0.01K / 0.16K / 18.62K

  OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME                   
3646503 3646503 100%    0.38K 173643       21   1389144K kmem_cache
3852288 3851906  99%    0.06K  60192       64    240768K kmalloc-64
3646656 3646656 100%    0.06K  56979       64    227916K kmem_cache_node
1441760 1441675  99%    0.12K  45055       32    180220K kmalloc-128
499136 494535  99%    0.25K  15598       32    124784K kmalloc-256
1066842 1066632  99%    0.09K  25401       42    101604K kmalloc-96
101430 101192  99%    0.19K   4830       21     19320K kmalloc-192
 19168  17621  91%    1.00K    599       32     19168K kmalloc-1024
  8386   7470  89%    2.00K    525       16     16800K kmalloc-2048
 15000   9815  65%    1.05K    500       30     16000K ext4_inode_cache
 66024  45955  69%    0.19K   3144       21     12576K dentry
369536 369536 100%    0.03K   2887      128     11548K kmalloc-32
 18441  16586  89%    0.58K    683       27     10928K inode_cache
 44331  42665  96%    0.19K   2111       21      8444K cred_jar
 12208   7529  61%    0.57K    436       28      6976K radix_tree_node
   627    580  92%    9.12K    209        3      6688K task_struct
  6720   6328  94%    0.65K    280       24      4480K proc_inode_cache
 36006  36006 100%    0.12K   1059       34      4236K kernfs_node_cache
266752 266752 100%    0.02K   1042      256      4168K kmalloc-16
134640 133960  99%    0.02K    792      170      3168K fsnotify_mark_connector
  1568   1461  93%    2.00K     98       16      3136K mm_struct
  1245   1165  93%    2.06K     83       15      2656K sighand_cache

Conclusions:

• The kernel's slab allocator is using about 2.3 GB of RAM
• Almost all of that is unreclaimable
• About 1.3 GB of it is occupied by the kmem_cache cache
• Another 0.5 GB belongs to the various-sized kmalloc caches

This is where I've hit a wall. I haven't figured out how to look inside those caches and see why they've gotten so large (or why their memory is unreclaimable). How can I go further in my investigations?

I have recently transitioned a Linux fileserver from offering only NFS v3 to also offering NFS v4. All of our clients happily started using NFS v4 automatically. Unfortunately, this effectively broke ACL management for the handful of users that use them, since the POSIX tools they're used to no longer work. (Worse, ls no longer indicates files that have ACLs, so they're more hidden than they used to be.)

I'm getting pushback from the users who don't want to learn new tools just because our storage system changed software (plus the fileserver is actually storing the ACLs on disk as POSIX ACLs, so the transition to NFSv4 ACLs feels a little silly, what with every system involved running some variant of Linux).

I can just force the clients to use NFS v3 for the users who don't want to learn NFSv4 ACLs, but is there a way to run NFS v4 clients but have the POSIX ACL programs work? Preferably without straying too far from the distribution's standard repositories.

The clients are running Fedora. (Currently they're on Fedora 23, but they get upgraded a lot, what with Fedora doing releases every six months or so.) The server is running Scientific Linux 7 and ZFS on Linux.

You can delete a ZFS filesystem (or other dataset) with zfs destroy <dataset>. That fails if the dataset has children, including snapshots. zfs destroy -r <dataset> will remove the filesystem and its children, but will also destroy any non-snapshot children of the filesystem. Is there a succinct way to say "Delete this filesystem and its snapshots, but only if it has no non-snapshot children"?

Basically, I have a number of nested filesystems and I'm using snapshots extensively, both for replication and for cheap backups. I would like a way to easily remove child filesystems and their snapshots (e.g. zfs destroy tank/container/leaf) while providing a modicum of protection against accidentally nuking the entire filesystem collection (e.g. zfs destroy tank/container<enter>leaf)

In case it matters, I'm using ZFS on Linux with Scientific Linux 7.

Solution:

Based on longneck's comment, I can do this with two lines:

zfs destroy tank/example/leaf@%
zfs destroy tank/example/leaf

I've tested it and it does exactly what I want.

Android Studio really seems to prefer to behave like it's running on a single-user system. Is there a good way to install it and the Android SDK on a Linux system in a way that minimizes the amount of per-user data it creates?

I've got a bunch of Fedora Linux client machines with hundreds of accounts. The accounts have relatively-small disk quotas and the default way to run Android Studio ends up dropping 2-3 GB of data into each user's home directory, between the SDK and the AVD images. I would like, if possible, to have Android Studio, the SDK, and the default AVD images installed centrally on each system (or, even better, on a NFS share that they all mount), in such a way that when a user starts Android Studio from the standard menu entry, everything just works without the user having to manually configure anything pertaining to the particulars of the system installation.

The systems that run Android Studio are all Fedora 23. (The NFS server is Scientific Linux 6, but that shouldn't really matter.)

I have a number of accounts on a Linux server that have filesystem quotas. I would like to email people only once for each of the following circumstances:

• The person goes over quota.
• The person's quota grace period ends.
• The person goes back under quota. (This one might be optional.)

In particular, I do not want a person who is over quota to get a new email every day until they go back under quota. They should get a maximum of three emails (one for each of the events above).

The standard warnquota program, as far as I can tell, simply emails everyone that's over quota every time it's run. That has the potential to generate a lot of mail and does not fit my requirements.

Is there another program that will meet my needs, or will I have to write something myself?

My file server is running RHEL 5. If I really need, I could mount its filesystem via NFS on a RHEL6 or RHEL7 system and run the quota-warning program from the client.

I'm running libvirt with QEMU/KVM and I have disk images for the VMs in LVM logical volumes. Naturally, many of the guest VMs use LVM for their disks, too.

I ran partprobe on my hypervisor and it detected all of the VM guest partitions, so now the LVM tools (pvs, vgs, lvs, etc.) list all of the guest's LVM entities along with the host's.

Is there a way to remove all of these LVM physical volumes from the host's knowledge (without affecting the guests, of course)? Rebooting the host isn't an option; several of these VMs need to stay running.

In case it helps, here's what the LVM layers look like, more or less:

/dev/sdb1 - host PV
  |
vg_hostname_vms - host VG
  |
  +-lv_vm1 - host LV, used as a disk image for vm1
  |   +-part1 - vm1 boot partition
  |   +-part2 - vm1 PV
  |       |
  |     vg_vm1 - vm1 VG
  |       +-lv_root - vm1 LV - /
  |       +-lv_swap - vm1 LV - swap
  |
  +-lv_vm2 - host LV, used as a disk image for vm2
      +-part1 - vm1 boot partition
      +-part2 - vm2 PV
          |
        vg_vm2
          +-lv_root - vm2 LV - /
          +-lv_swap - vm2 LV - swap
          +-lv_home - vm2 LV - /home

Now, when I run vgs, here's what I see:

VG              #PV #LV #SN Attr   VSize  VFree
vg_hostname_vms   1   2   0 wz--n- 10.91t 9.53t
vg_vm1            1   2   0 wz--n-  9.76g    0
vg_vm2            1   3   0 wz--n- 97.16g    0

I only want to see the host's volume groups (and only its physical and logical volumes).

I'm running all of this on a Scientific Linux 6.5 host. The guest OSes vary.

I have a system running QEMU/KVM (via libvirt). One of its VMs needs to have a presence on a subnet that is not local to the VM host. I have a Linux system on the remote subnet. Is there a way to set up some sort of tunneled bridge to cause the VM to appear present on the remote system? This will be a temporary situation (hopefully just until the VM owner can configure their system) and network performance and long-term maintainability aren't really issues.

To give some more concrete information:

My VM host has IP address 192.168.54.155/24. The VM has IP address 192.168.65.71/24. I have a remote system at 192.168.65.254/24. Both the VM host and remote system are running Scientific Linux 6.5. I do not control the network or routing in between the VM host and remote system. I do not have access to the guest OS on the VM. I would like traffic to the VM's IP address to end up at the VM even though its host isn't directly connected to the appropriate network.

I've tried using iproute2's tunnelling, but Linux won't let me add a tunnel to a bridge. I've considered using some sort of iptables mangling to route traffic over the tunnel and make the VM think it's on the right network, but I'm not sure whether there are better approaches. What's the best way to accomplish this hack?

I have sendmail set up to accept mail for a few domains and to relay messages for a few subnets' worth of systems. Recently a particular internal-use-only address has been receiving a lot of spam. I've been asked to simply drop any mail destined for this address unless the mail originated from one of the computers for which this system will relay mail.

I know I can do this with procmail, but I'd prefer to tie it into sendmail so that nonconforming email will be rejected outright at the MTA level. I can't figure out how to get sendmail to do this (or whether it's even possible).

I have sendmail configured with the following settings:

FEATURE(`access_db', `hash -T<TMPF> -o /etc/mail/access.db')`
FEATURE(`blacklist_recipients')

/etc/mail/access contains:

example.com              RELAY
connect:192.168.15       OK
to:[email protected]  REJECT

And I'm generating /etc/mail/access.db via makemap hash /etc/mail/access.db </etc/mail/access.

When I try to use that configuration, however, even local machines get 550 5.2.1 <[email protected]>... Mailbox disabled for this recipient messages when trying to send to the internal address.

Can I configure sendmail to do what I want and, if so, how?

In practically every example of ZFS usage that I've seen online (including several questions here), the zpool is named "tank". Why? Is there some sort of significance to the name or is it just that the original documentation used "tank" so that's what everyone else uses, too? If you have more than one zpool on a system, is it common to have one of them named "tank" or is "tank" only a convention for single-pool systems?

When there are errors during the initrd part of a system boot, dracut will drop to a shell (so you can fix things). Is there a way to require a password before going into the shell, in the manner that Debian's initramfs-tools rescue shell works?

I have several Fedora machines (currently Fedora 17, soon to be Fedora 20) run in a public lab environment. One of them had an fsck error today and dropped to the the rescue shell. Someone tried to use the system before I got to it (and, fortunately, didn't hit any of the commands available in the rescue shell). I'd like to prevent a recurrence.

This seems like it should be simple, but if it is, I must be missing something. I have a Linux NIS master from which I would like to be able to change users' passwords (in cases of forgotten passwords and similar things), but I can't.

Some details: I'm running Scientific Linux 6.4, with ypserv-2.19-26, ypbind-1.20.4-30, and yp-tools-2.9-12. NIS is configured to use /etc/yp/passwd for its passwd map (i.e. not the system passwd file). The system is a client of itself and ypwhich returns "localhost".

Because unprivileged users should not be logging in to the NIS master, we have the following set in /etc/nsswitch.conf:

passwd:     files compat

and this at the end of /etc/passwd:

+::::::/bin/false

In addition, /etc/pam.d/passwd contains the standard RHEL directives:

password   substack system-auth

/etc/pam.d/system-auth is a symlink to /etc/pam.d/system-auth-ac, which contains:

password    requisite     pam_cracklib.so try_first_pass retry=3 type=
password    sufficient    pam_unix.so md5 shadow nis nullok try_first_pass use_authtok
password    required      pam_deny.so

(As a side note, we're using md5 instead of sha512 because we have some Solaris clients that don't support sha512.)

If I run passwd as root, it prompts me for the new passwd, but then fails to change it:

$ sudo passwd phil
Changing password for user phil.
New password: 
Retype new password: 
NIS password could not be changed.
passwd: Authentication token manipulation error

The log file (/var/log/secure) is unhelpful:

passwd: pam_unix(passwd:chauthtok): password not changed for phil on ypmaster.domain.tld

If, instead, I run yppasswd, I can change the password:

$ sudo yppasswd phil
Changing NIS account information for phil on ypmaster.domain.tld.
Please enter root password:
Changing NIS password for phil on ypmaster.domain.tld.
Please enter new password:
Please retype new password:

The NIS password has been changed on ypmaster.domain.tld.

But that requires any sysadmin who needs to reset a password to know (or look up from our locked password safe) the system's root password, which is a scenario I'd like to avoid.

So how do I need to configure the master to allow us to change user passwords without having to type the system's root password every time?

I'm having problems with two systems (a Solaris client and Linux server) using NFS v3 to mount home directories. (NFS v4 simply doesn't work at all, for what I'm told by another sysadmin here is a "known issue".) NFS v2 appears to work properly.

My question is this: what are the tradeoffs between using NFS v2 and NFS v3? I need to make a decision as to whether to keep trying to debug this problem or just deciding to live with NFS v2 for this one client.

I know there's a file size limit with v2, although I've seen conflicting information -- is it a 2 GB or 4GB limit? There's also a performance penalty to v2; is it possible to quantify the speed limitations with v2 in a general way, or does that depend too much on the specific systems and networks involved? (For what it's worth, I've got gigabit Ethernet between the systems.) What other tradeoffs are there between the two? Are there any security issues I should be aware of?

This seems trivial, but I have a service in Solaris 10 that's running but SMF thinks it isn't.

I could probably get SMF to have the right status by stopping and then starting the service, but in this case the service is SSH, which means I have to be at the system console to restart it.

How can I tell SMF, "This service is really running; please move it into 'online' status?"

Edit: Some information requested about the ssh service:

The output of /usr/lib/ssh/sshd -d | head -1:

debug1: sshd version Sun_SSH_1.1

The output of ptree `pgrep sshd`:

453   /usr/lib/ssh/sshd
  11456 /usr/lib/ssh/sshd
    11459 /usr/lib/ssh/sshd
      11461 -tcsh
  20521 /usr/lib/ssh/sshd
    20524 /usr/lib/ssh/sshd
      20526 -tcsh
        22145 ptree 11459 20521 11456 20524 453

The output of pargs -e `pgrep sshd`:

11459:  /usr/lib/ssh/sshd
envp[0]: EDITOR=vi
envp[1]: GROUP=wheel
envp[2]: HOME=/home/philadm
envp[3]: HOST=radiance
envp[4]: HOSTTYPE=sun4
envp[5]: LANG=en_US.UTF-8
envp[6]: LD_LIBRARY_PATH=/opt/csw/lib/$ISALIST:/usr/local/lib:/usr/lib:/usr/dt/lib:/usr/local/ssl/lib:/usr/local/BerkeleyDB.4.2/lib
envp[7]: LOGNAME=philadm
envp[8]: MACHTYPE=sparc
envp[9]: MAIL=/var/mail//philadm
envp[10]: MANPATH=/opt/csw/share/man:/usr/local/man:/usr/man:/storage/lang/man:/usr/local/ssl/man
envp[11]: OSTYPE=solaris
envp[12]: PATH=/bin:/sbin:/usr/sbin:/opt/csw/bin:/usr/bin:/usr/local/bin:/usr/dt/bin:/usr/bin/nsr:/usr/sbin/nsr:/opt/hpnpl/bin:/usr/openwin/bin:/usr/sbin:/usr/bin
envp[13]: PWD=/var/log
envp[14]: REMOTEHOST=bastion2.example.com
envp[15]: SHELL=/bin/tcsh
envp[16]: SHLVL=1
envp[17]: SSH_CLIENT=192.168.1.45 45010 22
envp[18]: SSH_CONNECTION=192.168.1.45 45010 192.168.1.5 22
envp[19]: SSH_TTY=/dev/pts/2
envp[20]: TERM=xterm
envp[21]: TZ=US/Eastern
envp[22]: USER=philadm
envp[23]: VENDOR=sun

20521:  /usr/lib/ssh/sshd
envp[0]: EDITOR=vi
envp[1]: GROUP=wheel
envp[2]: HOME=/home/philadm
envp[3]: HOST=radiance
envp[4]: HOSTTYPE=sun4
envp[5]: LANG=en_US.UTF-8
envp[6]: LD_LIBRARY_PATH=/opt/csw/lib/$ISALIST:/usr/local/lib:/usr/lib:/usr/dt/lib:/usr/local/ssl/lib:/usr/local/BerkeleyDB.4.2/lib
envp[7]: LOGNAME=philadm
envp[8]: MACHTYPE=sparc
envp[9]: MAIL=/var/mail//philadm
envp[10]: MANPATH=/opt/csw/share/man:/usr/local/man:/usr/man:/storage/lang/man:/usr/local/ssl/man
envp[11]: OSTYPE=solaris
envp[12]: PATH=/bin:/sbin:/usr/sbin:/opt/csw/bin:/usr/bin:/usr/local/bin:/usr/dt/bin:/usr/bin/nsr:/usr/sbin/nsr:/opt/hpnpl/bin:/usr/openwin/bin:/usr/sbin:/usr/bin
envp[13]: PWD=/var/log
envp[14]: REMOTEHOST=bastion2.example.com
envp[15]: SHELL=/bin/tcsh
envp[16]: SHLVL=1
envp[17]: SSH_CLIENT=192.168.1.45 45010 22
envp[18]: SSH_CONNECTION=192.168.1.45 45010 192.168.1.5 22
envp[19]: SSH_TTY=/dev/pts/2
envp[20]: TERM=xterm
envp[21]: TZ=US/Eastern
envp[22]: USER=philadm
envp[23]: VENDOR=sun

11456:  /usr/lib/ssh/sshd
envp[0]: EDITOR=vi
envp[1]: GROUP=wheel
envp[2]: HOME=/home/philadm
envp[3]: HOST=radiance
envp[4]: HOSTTYPE=sun4
envp[5]: LANG=en_US.UTF-8
envp[6]: LD_LIBRARY_PATH=/opt/csw/lib/$ISALIST:/usr/local/lib:/usr/lib:/usr/dt/lib:/usr/local/ssl/lib:/usr/local/BerkeleyDB.4.2/lib
envp[7]: LOGNAME=philadm
envp[8]: MACHTYPE=sparc
envp[9]: MAIL=/var/mail//philadm
envp[10]: MANPATH=/opt/csw/share/man:/usr/local/man:/usr/man:/storage/lang/man:/usr/local/ssl/man
envp[11]: OSTYPE=solaris
envp[12]: PATH=/bin:/sbin:/usr/sbin:/opt/csw/bin:/usr/bin:/usr/local/bin:/usr/dt/bin:/usr/bin/nsr:/usr/sbin/nsr:/opt/hpnpl/bin:/usr/openwin/bin:/usr/sbin:/usr/bin
envp[13]: PWD=/var/log
envp[14]: REMOTEHOST=bastion2.example.com
envp[15]: SHELL=/bin/tcsh
envp[16]: SHLVL=1
envp[17]: SSH_CLIENT=192.168.1.45 45010 22
envp[18]: SSH_CONNECTION=192.168.1.45 45010 192.168.1.5 22
envp[19]: SSH_TTY=/dev/pts/2
envp[20]: TERM=xterm
envp[21]: TZ=US/Eastern
envp[22]: USER=philadm
envp[23]: VENDOR=sun

20524:  /usr/lib/ssh/sshd
envp[0]: EDITOR=vi
envp[1]: GROUP=philadm
envp[2]: HOME=/home/philadm
envp[3]: HOST=radiance
envp[4]: HOSTTYPE=sun4
envp[5]: LANG=en_US.UTF-8
envp[6]: LD_LIBRARY_PATH=/opt/csw/lib/$ISALIST:/usr/local/lib:/usr/lib:/usr/dt/lib:/usr/local/ssl/lib:/usr/local/BerkeleyDB.4.2/lib
envp[7]: LOGNAME=philadm
envp[8]: MACHTYPE=sparc
envp[9]: MAIL=/var/mail//philadm
envp[10]: MANPATH=/opt/csw/share/man:/usr/local/man:/usr/man:/storage/lang/man:/usr/local/ssl/man
envp[11]: OSTYPE=solaris
envp[12]: PATH=/bin:/sbin:/usr/sbin:/opt/csw/bin:/usr/bin:/usr/local/bin:/usr/dt/bin:/usr/bin/nsr:/usr/sbin/nsr:/opt/hpnpl/bin:/usr/openwin/bin:/usr/sbin:/usr/bin
envp[13]: PWD=/var/log
envp[14]: REMOTEHOST=bastion2.example.com
envp[15]: SHELL=/bin/tcsh
envp[16]: SHLVL=1
envp[17]: SSH_CLIENT=192.168.1.45 45010 22
envp[18]: SSH_CONNECTION=192.168.1.45 45010 192.168.1.5 22
envp[19]: SSH_TTY=/dev/pts/2
envp[20]: TERM=xterm
envp[21]: TZ=US/Eastern
envp[22]: USER=steveadm
envp[23]: VENDOR=sun

453:    /usr/lib/ssh/sshd
envp[0]: EDITOR=vi
envp[1]: GROUP=wheel
envp[2]: HOME=/home/philadm
envp[3]: HOST=radiance
envp[4]: HOSTTYPE=sun4
envp[5]: LANG=en_US.UTF-8
envp[6]: LD_LIBRARY_PATH=/opt/csw/lib/$ISALIST:/usr/local/lib:/usr/lib:/usr/dt/lib:/usr/local/ssl/lib:/usr/local/BerkeleyDB.4.2/lib
envp[7]: LOGNAME=philadm
envp[8]: MACHTYPE=sparc
envp[9]: MAIL=/var/mail//philadm
envp[10]: MANPATH=/opt/csw/share/man:/usr/local/man:/usr/man:/storage/lang/man:/usr/local/ssl/man
envp[11]: OSTYPE=solaris
envp[12]: PATH=/bin:/sbin:/usr/sbin:/opt/csw/bin:/usr/bin:/usr/local/bin:/usr/dt/bin:/usr/bin/nsr:/usr/sbin/nsr:/opt/hpnpl/bin:/usr/openwin/bin:/usr/sbin:/usr/bin
envp[13]: PWD=/var/log
envp[14]: REMOTEHOST=cbastion2.example.com
envp[15]: SHELL=/bin/tcsh
envp[16]: SHLVL=1
envp[17]: SSH_CLIENT=192.168.1.45 45010 22
envp[18]: SSH_CONNECTION=192.168.1.45 45010 192.168.1.5 22
envp[19]: SSH_TTY=/dev/pts/2
envp[20]: TERM=xterm
envp[21]: TZ=US/Eastern
envp[22]: USER=philadm
envp[23]: VENDOR=sun

I have a few lab environments where the computers get rebuilt on a periodic basis but need to keep the same ssh host keys so that the people who connect to the lab computers (often from their own systems not under my administration) don't get "host key changed" errors every time we upgrade the the lab systems' OSes.

(This is similar to the question Smoothest workflow to handle SSH host verification errors? but in this case we've already decided that maintaining the same keys across system rebuilds is the best solution for us.)

Right now, I have a Puppet module named ssh that has the following clause in it:

file { "/etc/ssh/":
  owner   => 'root',
  group   => 'root',
  mode    => '0644',
  source  => "puppet:///modules/ssh/$fqdn",
  recurse => true,
  require => Package['openssh-server'],
  notify  => Service['sshd'],
}

On the puppet master, each host has its own directory that contains all of the host key files (ssh_host_key, ssh_host_dsa_key, ssh_host_rsa_key, etc.), as implied by the file resource definition. My problem is that this feels like mixing code and data (since all of the host keys live inside a module directory) and I have to make another commit to the Puppet VCS every time I add a new set of hosts. Is there a better way to manage these things?

I have an iDRAC7 that came with an Express License. I have purchased an Enterprise license. What do I need to do to activate the license on my iDRAC7?

I've got NUT configured on a few systems in the following way: One host is connected to four UPSes via USB. That host is plugged into two of the four UPSes. Two other hosts are on the same rack, each plugged into one of the remaining UPSes. upsmon on the master only monitors the two UPSes relevant to powering that host, even though upsd is configured to communicate with all of them. upsmon on each of the slaves monitors the appropriate UPS attached to the master. I cannot have each slave directly attached to its UPS. (Those two hosts are VMware ESXis and the only NUT package I've found for them only contains upsmon.) (I also have another rack whose UPS configuration is sufficiently complicated that while I could have a setup where each UPS was directly attached to a host it powered, it makes for simpler cabling to have them all connected to a single host even if it doesn't draw power from all of them.)

My question is this: if the power goes out and one of the slaves' UPSes goes into low battery state, what is the best way to have the master power off the UPS as soon as the slave attached to it has shut down? I don't want to just wait for the master to shut down, because that leaves a window of time where the power might return but, because the slave's UPS never powered off, the slave's system will not see a power cycle and, thus, will not turn itself back on.

I have a pair of ESXi (5.1) hosts in a High Availability cluster. Each host has 48GB of RAM. I currently have 18 VMs running, with the following configured memory amounts:

• 1x 4GB, 1 vCPU
• 1x 4GB, 4 vCPU
• 5x 2GB, 1 vCPU
• 5x 1GB, 1 vCPU
• 4x 512MB, 1 vCPU
• 2x 512MB, 1 vCPU, with Fault Tolerance (so consumed memory is doubled)

That should add up to 27GB of RAM. Based on the Resource Management Guide (and assuming 38 MB overhead for a 2 GB, 1 vCPU VM and 23 MB for a 512 MB, 1 vCPU VM), there should be about 612 MB of overhead, for around 28 GB total.

When I look at the individual hosts, the memory in use appears to line up with that. On the Summary tab, for "Memory usage", one host shows 14240.00 MB and the other shows 14897.00 MB, for a total of about 28.5 GB.

The Resource Allocation tab for my cluster in the vSphere Client, however, shows the following:

• Total Capacity: 89705 MB
• Reserved Capacity: 47210 MB
• Available Capacity: 42495 MB

Setting aside the fact that 48 GB of RAM across two hosts is 98304 MB, not 89705, why is the reserved capacity so high? There's almost 20 GB between what the individual hosts claim to be using (28 GB) and what the cluster claims to be using (46 GB). Moreover, this is preventing me from adding new VMs, since the HA cluster needs to be able to tolerate the failure of one host and the software thinks I'm running at full capacity for that constraint.

All of my VMs are configured with no RAM limit and no RAM reservation, except for the two Fault Tolerant VMs, which have all of their RAM reserved.

This is with a vSphere 5.1 Standard license.

I have a server (Dell PowerEdge 2950) with a PERC 6/i and six disks. Two of the disks are in a RAID-1 with a third as a hot spare. I have been asked to make a copy of the RAID-1 data on one of the other disks in such a way that we can store the disk offline and, if needed, boot the system from the offline disk. I also need to be able to periodically update the offline disk while the system is running. (This disk would be part of our disaster recovery and would also serve as a "last known good" disk in case of something going drastically wrong with the server.)

My instinct is to partition one of the extra disks to match the RAID-1's partitioning, then mount the partitions, rsync over the data and put GRUB on the disk, but I cannot figure out how to configure the PERC 6/i's RAID to get this to work. If I create and then remove a RAID with the to-be-offlined disk, all of the data is deleted when the RAID is removed. If I create a RAID and just remove the disk, the controller becomes very sad. Since we're using RAID for the system disks, it doesn't look like there's a way to access one of the other disks without making it part of a RAID. Is there a way to do what I want?

I'm running Linux (RHEL 5) and using Dell's OMSA CLI programs (omreport and omconfig).

I felt that my question was mostly about how I could get the PERC 6/i to do what I want. In the absence of any pointers about that and based on the fact that I don't see a way forward from my reading of the documentation, I'm going to bypass the RAID controller and put my bootable system copy on a USB disk. This will supplement our RAID and tape backups and serve as a quick response to a few failure scenarios that would otherwise require downtime while restoring the system from tape.