All Questions(server)

When deploying applications onto servers, there is typically a separation between what the application bundles with itself and what it expects from the platform (operating system and installed packages) to provide. One point of this is that the platform can be updated independently of the application. This is useful for example when security updates need to be applied urgently to packages provided by the platform without rebuilding the entire application.

Traditionally security updates have been applied simply by executing a package manager command to install updated versions of packages on the operating system (for example "yum update" on RHEL). But with the advent of container technology such as Docker where container images essentially bundle both the application and the platform, what is the canonical way of keeping a system with containers up to date? Both the host and containers have their own, independent, sets of packages that need updating and updating on the host will not update any packages inside the containers. With the release of RHEL 7 where Docker containers are especially featured, it would be interesting to hear what Redhat's recommended way to handle security updates of containers is.

Thoughts on a few of the options:

• Letting the package manager update packages on the host will not update packages inside the containers.
• Having to regenerate all container images to apply updates seems to break the separation between the application and the platform (updating the platform requires access to the application build process which generates the Docker images).
• Running manual commands inside each of the running containers seems cumbersome and changes are at risk of being overwritten the next time containers are updated from the application release artifacts.

So none of these approaches seems satisfactory.

I run several docker containers with hostnames:

web1.local web2.local web3.local

Routing to these done based on hostname by nginx. I have a proxy in front of this setup (on different machine connected to internet) where I define upstream as:

    upstream main {
      server web1.local:80;
      server web2.local:80;
      server web3.local:80;
    }

And actual virtual host description:

    server {
      listen 80;
      server_name example.com;
      location / {
        proxy_pass http://main;
      }
    }

Now, because containers receive hostname "main" instead of "web1.local", they do not respond properly to the request.

Question: how I can tell nginx to pass name of the upstream server instead of name of upstream group of servers in Host: header when proxying request?

A few of us at my company have root access on production servers. We are looking for a good way to make it exceedingly clear when we have ssh'd in.

A few ideas we have had are:

• Bright red prompt
• Answer a riddle before getting a shell
• Type a random word before getting a shell

What are some techniques you guys use to differentiate production systems?

I have a constantly running script that I output to a log file:

script.sh >> /var/log/logfile

I'd like to add a timestamp before each line that is appended to the log. Like:

Sat Sep 10 21:33:06 UTC 2011 The server has booted up.  Hmmph.

Is there any jujitsu I can use?

I currently have this snippet:

# flush all chains
iptables -F
iptables -t nat -F
iptables -t mangle -F
# delete all chains
iptables -X

Is there a possibility that some impervious rule will stay alive after running this?

The idea is to have a completely clean iptables config, that can be easily replaced by new ruleset (nevermind routes/ifconfig's parameters).