Illustrating the Ubuntu clown car, AccountsService edition (2012) | Hacker News Reader

Illustrating the Ubuntu clown car, AccountsService edition (2012)

utcc.utoronto.ca

60 pointstshtf45 comments

The code does seem pretty bad. At the minimum, if such a hack is necessary for some reason, it should have been documented.

But let's be mature about this. Ubuntu is a combined effort and includes a lot of volunteer work. Have you sent a quiet note to the developer who wrote this code? His name is plainly visible on the quilt patch.

Why you have to call out open source code that you think is bad in an open forum? Have you looked at openssl recently, for example? Why is this worse? Or is it just because Ubuntu is everyone's favorite target at the moment?

You're being affected because of a pretty obscure use case (NFS home directories), which is something that the vast majority of Ubuntu desktop users do not use. Do you have a support contract with Canonical for your large enterprise deployment? If you don't and prefer to go it on your own, then why haven't you submitted a patch for this yourself?

Have you asked for a full refund?

If you don't like "the Ubuntu clown car", why are you riding on it at all?

I agree with this approach of pointing it out and shaming the gigantic turd.

The whole thing is a mess and there is absolutely fuck all you will get out of canonical by either mailing them or raising on launchpad, paid up support or not. I've been on the end of this sort of problem a number of times and only the interesting and easy to recreate issues are resolved (and some of them like two major MySQL issues I raised on an LTS release are unresolved after 3 years even though we were paid landscape and supported users).

And the approach the article points out is pretty normal if you have a LAN with multiple Unix style machines on it.

I expect the article writer is considering replacing clown cars with Volvos (debian stable).

> The whole thing is a mess and there is absolutely fuck all you will get out of canonical by either mailing them or raising on launchpad, paid up support or not.

It's open source. For some reason you seem to have unrealistic expectations here. If you're prepared to do the work to fix it, then you'll be heard. If you're not, then you'll only hear echoes of yourself complaining that the problem isn't being fixed.

If Ubuntu has introduced a patch over Debian or upstream, there's usually a reason for it. Here, it looks like it's adding some kind of useful functionality for standalone users.

> and some of them like two major MySQL issues I raised on an LTS release are unresolved after 3 years even though we were paid landscape and supported users

MySQL is a particularly sore point. Upstream (Oracle) have a closed VCS and bug tracker. There's very little that can be done about MySQL issues except to wait for Oracle to fix them. Slackware and Arch have already moved away from MySQL for this reason. If you have a packaging issue, then Ubuntu in time inherits whatever Debian's packaging have done there. There's little different between Debian and Ubuntu's MySQL packaging (they happen to mostly be looked after by the same person wearing two different hats, anyway).

I fail to see how Debian is better here in the general case. Ubuntu inherits most of Debian's goodness. In areas where differs, yes Ubuntu can introduce bugs not present in Debian. But it usually differs in the first place because there is extra functionality available in Ubuntu aimed at the everyday user.

Again, I think most of the complaints about Ubuntu are really complaints that the open source world isn't fixing your special issue. Ubuntu just tends to get the flak because it is popular. People have fewer expectations from other distros for some reason, even though they are all based on the same upstream sources.

It's not "open source specific" when you have a support contract with Canonical. Also if it's a high profile package, there is a moral obligation to do a proper job.

MySQL issue was fixed by a minor version upgrade on all other platforms including Debian stable! LTS should include that upgrade but it has been frozen at a broken version for 3 years. That is simply unacceptable and purely incompetent.

Debian are actually responsive and take defects seriously. Canonical actually break more stuff than they improve.

Seriously though, if I phone up Microsoft (we have a support contract along the same lines of Canonical), the actually get a fix to us in quite shockingly good times. We had an SQL server issue and we had a binary hotfix in two days flat.

Canonical just do a shit job - simple as.

A minor version upgrade violates Ubuntu's stable release updates policy, which is to backport fixes only. And as I've said, this is very difficult when MySQL upstream keep their VCS private.

An Ubuntu developer could try and get a micro release exception in place for MySQL, but as I say this is a MySQL-specific problem.

Canonical cannot trump Ubuntu policy.

Tracking minor versions was part of the LTS policy at the time as we had minor updates before the shit version got thrown at us. This is 10.04 for ref.

Were talking v5.0.30 -> v5.0.31 here (these aren't the actual versions as I don't have them in front of me).

Also it says in our support contract what the policy is. We no longer have any support contract - waste of money.

The security team have no option but to throw minor updates in for MySQL because upstream keep their security patches secret. Non-security updates don't currently get this treatment. It sounds like this is what happened to you.

Fair point - thanks for the clarification! :)

I though Canonical owns Ubuntu. They can policy whatever they want.

No. Ubuntu has its own community governance. Though Canonical does employ a number (perhaps the majority) of Ubuntu developers.

Policies are ultimately managed by the Technical Board and the Community Council, both of which have members who are not Canonical employees.

Mark Shuttleworth does have ultimate executive rights to do anything he wants, and he does own Canonical. So yes, Mark can set whatever policy he wants. But his use of this veto/executive ability is generally documented and he doesn't use it all that much. Certainly not in the details of MySQL and stable release updates.

I concur that reporting Canonical-caused bugs is pretty much futile.

I did network-admin work up to about 5 years ago in a small university deployment (a few dozen workstations), and we had the classical NFS+NIS setup that used to work more or less out of the box. Ubuntu itself was a nice distribution to administer, but even then a lot of the new X-kit and X-daemons that were developed to make single-user machines easier to run had flaws I had to work around.

But more often that not it seems that solutions are integrated as core-components in Ubuntu which are obviously not sufficiently thought trough: When a service for administering user-accounts is brought in, I'd at least expect someone to ponder how it will integrate with the different sources of user-account data (local files, NIS/YP, LDAP, Microsoft-AD, nss-sql-something-?, ...), and "iterating over all users(groups" is definitely a no-go in any large deployment.

Having to deploy this today would probably mean that I'd just disable that service, or replace it with a dummy, or re-code it in python, or ... but of course that would be one additional thing to "repair" in the default-install, and annoying to the sysadmin.

I have been bitten in similar ways by gdm; on 8.04 and 10.04 gdm would only read /etc/passwd, it would totally ignore nsswitch.conf. The patch to fix this was relatively easy to make but annoying nonetheless.

I've always been surprised that people bother installing Ubuntu on anything other than a personal laptop or desktop computer. Genuine question: what does Ubuntu offer as a server OS that isn't available in plain Debian?

Landscape

As a power user, I like updated packages on desktops without the hassle of running testing, and a debian-like system for servers with a predictable release date and packages newer than 1996 for servers.

I love Debian but Ubuntu really did wonders for Linux adoption. This said, wherever squeeze is modern enough, I will use it instead.

I'd rather have debian stable. At least the packages actually work. Ubuntu is so damn unreliable (even LTS).

>unreliable (alt)

I would have disagreed with you until a few weeks ago. The past few updates have been requiring us to restart our servers. You restart it and a day later there is another update that requires another restart. Putting off updates on production servers is no longer a choice but having them now is not the best thing either.

To be honest this is the least of our problems. We can reboot parts of our cluster without affecting overall capacity much. You just chuck the machines out of the load balancer pool and reboot them.

The issue is versions being pinned on LTS packages to broken versions. This includes svn, MySQL and a notable gcc problem which is a PITA.

I guess these are kernel security patches. You know why there are no patches for Debian stables? Because, no one bothers anymore to find stuff in 2.6

Are blackhats finding stuff? If not, sounds good.

Considering a big chunk of 3.x is the same as 2.6... hmm.

cloud-init for programmatically configuring new instances https://help.ubuntu.com/community/CloudInit

Puppet/dd?

The five year Long Term Support edition.

3. Some newer packages. 2. PPAs. 1. It's actually supported by hosting companies.

We use 10.04 (and soon to be some 12.04) at work. The server edition is pretty much a version of Debian. As a sysadmin, I like it a whole lot.

Canonical indulge in mind-boggling WTFery on the desktop - but on the server underpinnings, they actually contribute a lot of paid developer effort directly to Debian to keep things going.

Reporting bugs that were caused by Canonical is pretty much futile, though. With Ubuntu Server you get to keep both pieces just as you do with Debian, it's just they're pretty okay pieces.

FWIW I have seen a lot more Debian support from hosting companies than Ubuntu support. Either way it's overwhelmingly RedHat.

Honestly though, problems surrounding "newer packages" is the reason #1 I avoid Ubuntu. I think the problem I had might have been LTS-specific, but I expected it to break less with changes, not more.

Ubuntu has lots of releases, so you don't need to sit on a broken piece of technology for ages. Oh and there is no gnome-shell in Debian stable.

Imho using an Ubuntu release is gradually easier than following Debian testing.

And Ubuntu is security hardened. Take a look at this list, Apparmor, stack protection, (more) secure sysctl settings:

https://wiki.ubuntu.com/Security/Features

Excuse my ignorance, but this is a desktop tool. How does a single desktop machine have hundreds or users and groups?

A common pattern in administering large Linux workstation installations is having the machines poll a central user database which generates new group/password files. Of course ideally you can pull a subset, but if everyone needs to be able to log into that workstation, then everyone needs to be in /etc/passwd. There are other solutions, but this is a simple and effective one that means most people can still log in if your authentication servers are down.

Why do hundreds of people log into one workstation? Or do you mean each person to their own workstation, but they all share a common passwd file?

One example where hundreds of people need to be able to physically log into a single workstation is an educational computer lab where you have a 20 or so shared workstations, and requiring assigned seating would be cumbersome. Having a common passwd file for personal workstations is also an understandable configuration for ease of administration, though it of course has its drawbacks.

Imagine a company with 100 employees, and 100 shared workstations.

Now imagine everyone has to be able to log on to each workstation.

In our case we run servers and then have thin desktops (using LTSP) that actually log in and run their sessions on the servers. The servers carry our entire password and group file because everyone can log in to them.

In general, in any NFS based environment all machines that NFS-mount common filesystems need to carry a full collection of login and group information so that things like 'ls -l' work on the NFS filesystems. If you want everyone to be able to log into every machine, they also need some sort of password information as well (either by distributing shadow files or by various other means).

Why do people use NFS in this decade, when we have stuff like FUSE to put a file API on top of reliable networking tools?

NFS is an unstable buggy mess suitable only for light personal use. I have never been at an org that wasn't actively migrating off of legacy NFS , and that ended years ago.

Our experience is that NFS works excellently in the environment it was designed for (a LAN environment of Unix machines administered by the same people). I still haven't seen a better Unix remote filesystem (and most of the modern distributed filesystem efforts are solving different problems, as seen by the fact that they don't support full core Unix semantics).

With that said, the environment NFS was designed for is increasingly uncommon. NFS is not necessarily a good fit for other environments, even if they look superficially similar.

This is from August of last year. Is it still relevant?

The bug mentioned still appears to be open, though there's progress: https://bugs.launchpad.net/ubuntu/+source/accountsservice/+b...

The code mentioned in the post is also still in the latest version of the package's code on Launchpad: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/raring/a...

From reading the post it seems fixing the three issues mentioned would have been faster than writing all this. Honestly, if you can understand the code, those are really minor things.

If they aren't that hard to fix, why hasn't Ubuntu fixed them? Remember, this guy had a support contract.

I think there's been a misunderstanding. We (the people who ran into the accountsservice problem) don't have a Canonical support contract. hp50g, who commented upthread, is the one who had the Canonical support contract.

We did 'fix' these issues as soon as we managed to track down why the daemon was using up so much CPU time on our machines. I wrote my entry partly because I was annoyed at how terribly badly thought out the code was and partly to warn other people.

(We have never tried to feed the 'fix' upstream because our fix simply hardcodes some answers. I don't think it's even possible to fix the code to do what Ubuntu apparently wants it to do, although it could be less catastrophically inefficient.)

Is re-reading group file really that bad? OK it's pretty stupid but the file will be cached after the first read so it's not like the disk is being hammered constantly.

The problem (for large sites) is the CPU usage required to repeatedly re-parse and re-process the group file; this is apparently not insignificant for large group and password files. IO isn't an issue because as you note, it'll be cached.

This is absolutely shocking.

Reply on news.ycombinator.com