iconoclast's questions

In general (as far as I can see) the main infrastructure/configuration management systems (Puppet, Chef, Ansible, and SaltStack) are based on the philosophy that your servers are "cattle" and not "pets", and it seems that they can be antagonistic to the idea that you would ever make a configuration change directly to a server.

Although I've worked with Chef and Puppet and Salt, it has always been from the point of view of a developer working with Vagrant to get individual boxes set up for development, so my experience doesn't help answer this question.

The question is: do any of these systems support the use case where you make a change directly to a server, and leave it there for a time without worrying that a local daemon is going to overwrite it with the official configuration? You should be able to make the change (and ideally set the time window during which it is protected from overwriting) without any significant changes to (e.g.) Chef recipes or Salt states. The whole purpose of this use case is to avoid letting a five-minute configuration change be bogged down by corporate friction and the complications of finding the right (e.g.) salt state and making sure there are no side effects and going through the release/deployment cycle and testing to make sure you didn't bork anything in the process.

If you want a more concrete example, suppose you want to adjust your logrotate settings for a number of logs, to balance saving drive space and access to historical data. You have an idea of how much data you'll save at any given setting, and how much data you think you need to keep, but you're not 100% sure. It would be nice to start out just making the change, and seeing (1) anyone complains that they need more historical data for some debugging task, or (2) you're not saving as much drive space as you expected and need to save.

A five-minute change can actually be a five minute change, if your configuration mangagement system allows it to be one, and then once you're positive that you want those changes on all of your boxes that fulfill a particular role, you can letting Chef/Puppet/Salt/Ansible manage that for you.

Note: I'm not asking about a use case where the config management system is not yet managing a certain type of config file, but a case where it is already managing a certain type of config file, but you want to make local changes and have them take precedence on that given machine, and not get overwritten.

Do any of these systems support my use case? (Without requiring me to fight with the system or do backflips to make it work.)

Within a ~/.ssh/config or ssh_config file, %h will give you the HostName value, but how do you get the Host ("alias") value?

Why would I want to do that? Well, here's an example

  Host some_host_alias
    HostName 1.2.3.4
    User my_user_name
    PasswordAuthentication no
    IdentityFile ~/.ssh/some_host_alias.rsa.id
    LocalCommand some_script.sh %h    # <---- this is the critical line

If I pass %h to the script, then it uses 1.2.3.4, which fails to give it all the options it needs to connect to that machine. I need to pass some_host_alias, but I can't find the % variable for that.

(And: yes! I'm aware of the risk of recursion. That's solved inside the script.)

UPDATE: Kenster pointed out that I could just hard-code the Host value as an argument to the script. Of course this will work in the example I gave, but it won't work if I'm using pattern matching for the Host.

I have a new server and am planning to upgrade the paltry 2 GB of memory to the maximum of 16 GB. (Theoretically 8 GB is the limit, but empirically 16 GB has been shown to work.) Some guides advise that ECC memory is not that important, but I'm not so sure I believe this.

I've installed FreeNAS and am planning to add ZFS volumes as soon as my new hard drives arrive. Would it be stupid to skimp and get non-ECC memory for a ZFS-based NAS? If it's necessary, then I'll bite the bullet, but if it's just paranoia, then I'll probably skip it.

Is there any reason ZFS or FeeeNAS specifically would require ECC memory, or suffer especially when running on a system using non-ECC memory?

Picture a scenario where I'm logged into a server (which we'll call "Wallace") from my local machine, and from there I ssh into another server (which we'll call "Gromit"):

laptop ---ssh---> Wallace ---ssh---> Gromit

Then the ssh session from Wallace to Gromit hangs, and I want to kill it. If I enter ~. to kill ssh, it kills the ssh session from my laptop to Wallace, because the ~ is intercepted by that ssh session, and the . is taken as a command to kill the session. How do I send a command to the ssh session between Wallace and Gromit? How do I kill my "inner" ssh?

I'm comparing two Apache config files (httpd.conf), one on a CentOS 6.2 VM with Apache 2.2.15 and one on a RedHat 5.8 server with Apache 2.2.3, and I see a strange difference.

UserDir disabled                                          |     UserDir disable
# directory, remove the "UserDir disabled" line above, an |     # directory, remove the "UserDir disable" line above, and

In one case UserDir disabled is used, and in the other UserDir disable is used. Didn't see the difference? One ends in d and the other doesn't—one uses an adjective referring to the resultant state of UserDir, and the other uses a verb telling what Apache should do to UserDir.

Which is right? Will both work?

UPDATE: Given that this appears to be a sysadmin error, and not a change in syntax from one version of Apache to another, or a mistake in RedHat's distribution of apache, I'm thinking this question may be useless to others and I should delete it. Thoughts?

I'm planning to build a FreeNAS box sometime soon, but if ZFS on Linux eventually proves to be reliable, I might want to switch, just to have a more familiar OS.

So I'm wondering if I can trust that the different implementations of ZFS are compatible. In other words, if I just swap out the boot disk from FreeNAS to Linux or OpenIndiana, can I trust that nothing bad will happen to my data?

This may seem like a stupid question--obviously it ought to be compatible--but I'm guessing that ZFS isn't commonly used in cases where drives are moved between computers, so I'm hoping someone can provide a better answer than just "it ought to be".

I'm considering switching from screen to tmux, but I've invested lots of time developing an extensive .screenrc, and I don't want to find after many hours of porting it to tmux that tmux can't do something that is important to me.

I've looked at several online comparisons of the two, and none of them go into much depth or answer many of (what are to me) the important questions, which can be boiled down to two questions:

• Is there anything significant that screen can do that tmux can't do?
• Is there anything significant that tmux can do that screen can't?

(The client-server architecture is nice, but doesn't give any new capabilities as far as I can see. The license is obviously better. Smaller and leaner is obviously nice, but not a game changer for me.)

Since these 2 questions are very broad, let me give some specific examples:

• Does tmux have a complete command history? (For commands sent to tmux itself, not shell commands. This is something that screen is missing: How can I go back in the (GNU) screen command history? (NOT shell command history!))
• I assume I can bind keys to tmux commands?
• I assume my tmux configuration file can source other files?
• Can I bind a keystroke to the source command, so that I can dynamically change my configuration easily?
• Does tmux have ACL settings? (I've never actually needed these in screen, but it's nice to know they're there.)
• Can tmux open default windows? (a la screen -t somename 1 ssh someserver)

I could hunt down answers to these specific questions myself, but they're just examples of the 2 bigger questions, and I'd also like to hear answers to the bigger questions that don't necessarily fit any of my examples. It's entirely possible that if there's something missing from tmux I wouldn't discover it after spending lots of time switching, and that's what I want to avoid. Thanks!

Currently, when I enter ^a : (control-A followed by ':') to send a command to GNU screen, I can go back one step in the history, and see exactly ONE previous command. This is really annoying, as I'm used to being able to go back thousands of steps in my shell history, and I'd like to be able to save at least a few dozen screen commands as well.

How can I do this?

bash refuses to give me the output of 'bind -p' when I pass it in with the -c switch:

bash -c 'bind -p'

but it works to type

bind -p

directly at the bash prompt, and it works to type something like

bash -c 'echo "hi"'

and zsh happily does exactly what bash refuses to do (well, the equivalent command in zsh):

zsh -c 'bindkey -L'

What on earth is going on???

(I've asked this question regarding zsh, but I also use bash and would find it useful there too--as I'm guessing many others would too since bash has many more users than zsh.)

I'd like to set up command completion on bash to display host names after I type

ssh [TAB]

taking the names out of my .ssh/config file (and preferably from known_hosts and /etc/hosts and anywhere else that makes sense) and presenting one single list.

It does some of this currently, but

1. it doesn't use .ssh/config at all
2. it requires a username first, even though using .ssh/config makes typing usernames unnecessary
3. it presents multiple lists (probably one from known_hosts and another from /etc/hosts, but I haven't verified that)

So I want to be include known usernames as well as known hostnames in the (preferably single) list after typing ssh [TAB]

(I'm coming here before Google because 1) it'll result in the answer getting stored here, and 2) it's probably more efficient. If no one else answers, I'll hunt down the answer.)

I'd like to set up command completion on zsh to display host names after I type

ssh [TAB]

taking the names out of my .ssh/config file (and preferably from known_hosts and /etc/hosts and anywhere else that makes sense) and presenting one single list.

It does some of this currently, but

1. it doesn't use .ssh/config at all
2. it requires a username first, even though using .ssh/config makes typing usernames unnecessary
3. it presents multiple lists (probably one from known_hosts and another from /etc/hosts, but I haven't verified that)

So I want to be include known usernames as well as known hostnames in the (preferably single) list after typing ssh [TAB]

(I'm coming here before Google because 1) it'll result in the answer getting stored here, and 2) it's probably more efficient. If no one else answers, I'll hunt down the answer.)