Monica For CEO's questions

Is it possible to specify a systemd dependency on any one of multiple units?

Currently, I have a unit Z that depends on at least one of unit A or unit B.

Configuring unit A to be WantedBy unit Z and unit B to be WantedBy unit Z mostly works.

However, if only one of units A or B is able to start, the boot process waits for the other unit to timeout before starting unit Z. I want to eliminate this timeout.

Units A and B require a timeout in order to function properly, however, once once of them has started, there is no need to wait for the other unit to timeout before starting unit Z.

Is there a way to specify that unit Z depends on either unit A or unit B, but does not need to wait for both unit A and unit B before starting unit Z?

In the Debian world, the packaging system uses Provides to specify something similar to what I'm hoping to accomplish here.

What I'm Trying To Accomplish

Debian used to support a keyscript option in crypttab but did not reimplement that option when upstream rewrote the startup scripts for the move to systemd. Previously, I used a keyscript to read my key from a USB drive. Currently, I am using a systemd unit file to take the place of the keyscript option (unit A). That works perfectly. However, USB drives are prone to failure, so for redundancy, I want to carry a second copy of my key on a second USB drive. And I want to add a second systemd unit file for that second USB drive (unit B), so that whichever USB drive is inserted, systemd is able to use that USB drive and continue without a timeout.

Other Things I've Tried

Using Conflicts to specify that A conflicts with B, and B conflicts with A. Unfortunately, systemd processes the conflict before attempting to start either of units A or B, and removes one of these units from the scheduler before trying to start the remaining unit. So Z sometimes fails, for example, if A fails, but B would have succeeded, if B was already eliminated from consideration due to the conflict with A.

Using JobTimeoutSec to shorten the timeout. Unfortunately, this can result in Z failing, if A and B timeout.

Michael Hampton's suggestions. As he mentions, the NTP example creates a weak dependency between each client and the target. Each NTP client wants the target, but the target does not depend on each of the NTP clients, so this works. However, as best I can tell, a weak dependency does not pull in the unit unless the unit also has an [Install] section specifying an additional dependency. So when I pull in my units A and B, the WantedBy in the [Install] section creates the blocking timeout. If I remove the [Install] section, units A and B are ignored.

Some services (nginx, buildbot, et cetera) only support logging to a file. Is there a way to reliably capture these log messages using syslog and friends, so that the log message can be reflected in the system logs and/or forwarded to a log service on another server?

Would it be feasible to create additional devices like /dev/log and point the service to log to those? In this case, would it be necessary to use some sort of wrapper in order for the service to open and write to /dev/log just like any other file?

Or would it be feasible for syslog to create a UNIX socket listener, and for a service to open and write to that just like any other file?

A Debian box is running web services on ports 80 and 443 and iptables is configured to allow web traffic only from white listed ip addresses.

A second Debian box (that is not white listed) is using nmap to run a port scan against the web server and is correctly showing that all ports are closed, however, the nmap scan results sometimes include the following:

sendto in send_ip_packet_sd: sendto(4, packet, 44, 0, X.X.X.X, 16) => Operation not permitted
Offending packet: TCP X.X.X.X:53268 > X.X.X.X:443 S ttl=43 id=46849 iplen=44  seq=955188003 win=1024 <mss 1460>

Port 80 is never mentioned in the scan results -- only port 443.

Why is port 443 (but not port 80) being exposed to nmap?

How are the routing tables populated on a Debian system? I understand that the ip route family of commands can be used to manually manipulate the routing tables, but how are the routing tables initially populated on system start, and under what circumstances are the routing tables updated?

Approximately how many bits of entropy are contained in each byte read from /dev/random and /dev/urandom? Data from /dev/random uses the kernel random-number generator while /dev/urandom uses a CPRNG so although the number of bytes read from each may be identical, the amount of actual entropy read from each would not be identical.

Are there any best practices and/or studies estimating how much entropy is generally contained in each byte of data read from these sources?

For example, if I needed 80 bits of entropy for a secure token, and the token was being generated by reading data from dev/urandom, and if I knew that each byte of data read from /dev/urandom would contain approximately 4 bits of entropy, I could read 20 bytes of data and use a hash function to generate the token.

On Apache 2.4, reload succeeds but restart fails when using SSL. Or to say it another way, the SSL configuration directives appear to work perfectly when doing a service reload but not a service restart.

The following sequence of commands:

service apache2 start
a2ensite secure.example.com
service apache2 reload

Allows me to browse https://secure.example.com without any errors, but a subsequent service apache2 restart with no interim changes to any configuration files causes apache2 to fail to start, with the message:

The apache2 instance did not start within 20 seconds. Please read the log files to discover problems

I can then use:

a2dissite secure.example.com
service apache2 start
a2ensite secure.example.com
service apache2 reload

And again access https://secure.example.com. The situation seems to be related to the use of SSL, as I can comment out the SSL configuration bits from secure.example.com and do an Apache restart without any issues.

Ubuntu 13.10, Linux 3.0.20-xenU, Apache/2.4.6 (Ubuntu), OpenSSL/1.0.1e

From man 8 sshd with regards to the Authorized Keys File Format and the command="command" option:

Note that this command may be superseded by either an sshd_config(5) ForceCommand directive or a command embedded in a certificate.

Using ssh-keygen -O force-command="command" allows a command to be embedded in a certificate. But how does one verify that a command has not been embedded in a certificate? Along these same lines of preventing unexpected commands from being executed, does ForceCommand always override a command embedded in a certificate?

Can a malicious user bypass a ssh authorized_keys forced command? asks a more general question about security but currently the answers there do not mention commands embedded in certificates.

I am using rsync --rsh "ssh" to push to a mirror. Setting the necessary file system permissions on the mirror requires rsync to run with root privileges on the mirror. However, the mirrored files are under a single hierarchy and I would like to allow rsync to access only that hierarchy and nothing else on the mirror.

How would I allow rsync to set permissions while also limiting access?

Is there possibly some combination of rsync --rsh "???" and the command="???" option in authorized_keys that might do the trick? The rsync command is already using a dedicated key in authorized_keys.

Or is there a way for rsync to connect as an unprivileged user, be jailed, and then gain access to set file system permissions? Jailing the process is easy, but allowing the remote rsync to gain privileges seems difficult, and allowing a jailed process to gain any permissions seems risky. (Of course, right now the process has root and any degree of restriction would be an improvement, even if only to mitigate accidents.)

I manage a number of Debian servers and usually track the Debian stable repository but occasionally install from the Debian testing repository or third party sources. For audit purposes, on each machine, for all packages currently installed, I would like to compare the installed package version against the package version in a particular repository, ie the Debian stable repository.

Using aptitude search patterns I can identify installed packages that are or are not available from the Debian stable repository:

aptitude search "?installed?origin(Debian)?archive(stable)"
aptitude search "?installed?not(?origin(Debian)?archive(stable))"

But for the packages that are available from the Debian stable repository I am not able determine whether the installed version matches the version in the repository.

I suppose it might be possible to use apt pinning to force a downgrade:

Package:      *
Pin:          release n=stable, o=Debian
Pin-Priority: 1001

And then use dry run mode to check which packages would be affected:

apt-get update
apt-get --dry-run upgrade

But mitigating the risks of using apt pinning over 1000 would require a separate configuration for apt, which seems more complicated than it needs to be.

A possibility going forward would be to set up a private repository, and only install from the Debian stable repository or the private repository. Then, if a package was available from the private repository, it could be assumed (for audit purposes) to not have been installed from the Debian stable repository. As long as packages are never installed manually, this could work reasonably well. But setting up a private repository seems a bit overkill for what could be one simple command.

Is there a better way to audit package versions? Or even better, to audit package signatures?