One approach to updating (and making PCI DSS-compliant…) Ubuntu cloud images would be to start a stock instance with an unmodified image, customise this VM, and then either snapshot or save and convert the resulting filesystem. The two drawbacks of this methodology are that the resulting image isn’t necessarily pristine – the commands run to migrate its state and and temporary files will still be present – and the image will be much larger than the original compressed/deduplicated source. This latter aspect is important when there is a need to spin-up a large number of VMs quickly, and the smaller the source image the faster this can occur.
I’ve recently been working on upgrading the stock Ubuntu cloud image(*) to meet the requirements for PCI DSS compliance – and a hugely non-obvious issue I ran into went as follows:
# passwd newuser passwd: Module is unknown passwd: password unchanged
It’s not uncommon, especially when using chroot() gaols, to find that “modern” systemd-equipped Linux distributions seem to get a bit possessive when it comes to mounting filesystems such as devtmpfs on /dev or tmpfs on /run, and when you want to remove the gaol this filesystems can show as still in use – although lsof/fuser -m output suggests that everything using root-dev and nothing respectively are actually using these mount-points.
Gentoo have recently taken the positive step of removing Intel-specific USE flags from builds directly, and introducing the new ‘CPU_FLAGS_X86‘ variable to control platform-specific hardware options.
(Presumably this opens the option for extensions such as ‘CPU_FLAGS_ARM="neon"‘, etc., in the future also…)
There is a new build app-portage/cpuinfo2cpuflags which will determine this information – but really, this feels like something that we can figure out canonically for ourselves without needing to pull-in additional packages 😉
For a while now I’ve been intending to make more use of a Kimsufi dedicated server I have, and making use of its datacentre-hosted location for remote connectivity testing seems like a good plan.
Having given OS X Server a trial-run, I suddenly found that I was encountering all manner of weird system issues:
- From the Apple menu, About This Mac, Restart…, Shutdown…, and Log Out… could be selected, but did nothing;
- Complaints when trying to restart/shutdown or when trying to perform other tasks that another user was logged-in and blocking the action;
- Restarting from the login screen cleared the screen to grey (and still be a usable mouse-cursor) but progressed no further;
- Graphical logins failing after a reboot as if the password was wrong, despite the same password working for SSH access – but only after a warm restart. Cold-booting still allowed login as expected;
- Multiple un-named “Admin” accounts in System Preferences’ Users & Groups pane, one of which could not be removed.
Removing OS X Server (drag the application to trash and manually remove /Library/Preferences/com.apple.server* and /Library/Server) didn’t resolve the issue.
It turns out, though, that the problematic behaviour is due to tools which are a part of Xcode but which are invoked by OS X Server – and the fix is maddeningly simple:
To disable the Xcode Server components with:
sudo xcrun xcscontrol --shutdown # Stops Xcode Server
… in order to shutdown all of _xcsbuildd’s processes and prevent restart from being blocked.
However, if you don’t actually need Xcode Server, then running:
sudo xcrun xcscontrol --reset # Resets Xcode Server, removing all service data and stopping all services
… will totally remove all users, services, and system changes. Running this resolved all of the above problems. If only Apple had mentioned this before OS X Server enabled Xcode Server in the first place…
bash standard library project: github.com/srcshelton/stdlib.sh
Give it a try 😉
HP Virtual Rooms supports Windows (primarily), Mac OS, and Linux.
Getting things working on Linux, however, takes a bit of elbow grease…
After a colleague with a PhD in Networking and myself spent the best part of a day trying to NAT UDP syslog packets without success (the Destination-NAT half is fine, but Source-NAT eludes: the external system still sees the internal IP), I decided to change tack and solve the problem by handling packets in user-space.