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…
Valve have been busy with Steam recently – amongst the recent launches an updated front page, targeted curated views, and a new music player feature.
However, there are still many (and indeed growing numbers of) rough edges and ill thought-out features.
On the 13th September, the AdBlock team posted to Google+:
We at AdBlock believe that our users should have freedom. That’s why we block all ads by default and release our code for anyone at http://code.getadblock.com
… but apparently their belief in their users’ freedom doesn’t extend to mentioning that this code is available in a trackable, versioned form at github.com/srcshelton/adblock, because they removed my post saying this!
Now that, I have to say, is just rude…
Not just that, the AdBlock project was also so careless when implementing this “feature” that every other website can track AdBlock users as well. And they explicitly allowed Disconnect.me to be notified whenever some AdBlock user starts up his browser.
… but also criticised AdBlock for being a GPL-3 open-source project with no public repository, and only per-release zip archives being made available. This means that it is non-trivial to determine what changes have been made between versions, and generally increases suspicions that someone somewhere is hiding something…
To remedy this, and as is my right according to the GPL-3 license under which AdBlock releases are made available, I have extracted each AdBlock release which is still available, and uploaded it to github at the following location:
… and I’ve a mind to fork this code-base and add DNT support if the user has enabled this option in their browser.
For balance, Michael’s response is at http://blog.getadblock.com/2014/07/adblock-and-privacy.html where he makes a point-by-point rebuttal.
I must admit that I’m still with Wladimir on this one – if AdBlock were doing nothing that they feel their users would object to, why not ask their users permission or, failing that, at least post – either within the extension or on their site – details of what tracking and what partnerships are active within a given release? Michael’s assertion that “User IDs are randomly generated and aren’t retained across different machines, browsers, or reinstallations” entirely misses the point that, for a given installation in a given browser, he had created a constant global tracking ID that can be used to uniquely identify the user, regardless of the preferences the user has expressed regarding whether they’re happy to be tracked or not.
Further to my 2010(!) post Installing Steam on Mac OS with a Case-sensitive boot partition Steam is now, if anything, even more broken on Mac OS – and this is particularly odious given that a Linux Steam client is now available which operates under the same conditions, but handles itself correctly.
Valve, why do you hate Mac gamers?