A gnome desktop and 3000 printers

We have something like 3000 printers. They are named something like “MF2301” and “MF2302”. The printer properties luckily show the location of the printer.

So let’s fire up system-config-printer and search for the right printer. First thing is that it takes ages for system-config-printer to start with 3000 printers. Somewhere close to 20 seconds. What’s happening? Is it requesting the status for each printer? Is the delay caused by 3000 icons (Nautilus is faster when displaying a directory with 3000 files)? Then we have the search field. Hmmm it allows only searches on the name, not by location or description. Unfortunately our users are humans and not computers, so they usually know the location where they are, but not the number of the printer. So I first have to walk to the printer, write the name down and walk back to my thin-client to select the correct printer and click “set as default”.

Now I want to print something. So I hit <ctrl><p> in openoffice.org, and it shows MF00001 as printer? That was not my default printer! Openoffice.org shows a dropdown with all printers, so I have to scroll through the 3000 printers to select the right printer again.

So far for printing for now.

Update: let me be clear, I don’t want to bash the developers of the printer settings (I’m very glad it exists!!!!) but I just want to show some of the issues that arise in large desktop deployments.

New desktop GUI’s and terminal servers

Gnome shell, but also Unity, make extensive use of modern video hardware possibilities. Which is a good thing. The downside is that they do not function anymore without access to the modern video hardware. In an organisation that uses thin-clients and terminal servers over a wide area network this becomes a bit of a problem. Protocols like NX (Nomachine) and VNC (many products, such as ThinLinc) that can handle the high latencies on wide area networks do not provide access to these functions of the video hardware.

This means that the thin-clients are limited to the “fallback” gnome desktop. But how long will that be maintained? When will the first open source product decide to drop support for the oldfashioned gnome desktop? What if Empathy or Networkmanager will not work anymore with the fallback desktop? Does that make our thin-clients worthless?

What is your strategy regarding thin-clients?

Storage and backup for desktops and laptops in the enterprise

For desktops it is generally considered a good idea that all user created data is stored on a NAS on which backup and restore is implemented.

For Linux desktops NFS is commonly used. However, NFSv3 is usually not acceptable because in large organisations there is too little control over IP adresses. So NFSv4 with Kerberos authentication is the answer. Large organisations also tend to have large networks, so latency is another factor, and again NFS4 (with the delegation feature) allows better client side caching. There is also FS-Cache/CacheFS that does a lot more caching on clients, but it does not improve performance in all situations (if bandwidth is not an issue don’t use it).

But now laptops. What you would like for laptops is the situation where the users work locally with their data, but whenever they have a network connection the data is synchronised to the enterprise NAS. That way they can disconnect their network at any time and continue working. There is the OFS (offline file system) that works on SMB network file systems, but that seems to be not completely mature yet. A second problem with laptops is authentication. A user may want to log on locally without network, and then connect the laptop to the network and expect it to start sychronising data. But that won’t work unless we first get our Kerberos ticket. I wonder what Windows laptops do in this situation, would they cache the password and re-use in the background to obtain a Kerberos ticket? Related to this: you need a feature sometimes called “cached credentials” to allow you to log on locally if your kerberos/ldap server is not available. There are some projects trying to adress this, but this is also still not well integrated yet.

Printing in the enterprise

In an enterprise organisation there might be 10000 to 100000 users, and 1000 to 5000 printers. There are a couple of tricky things in such a situation.

First is print queue scalability. Converting the print job to the right format for the right printer is quite CPU intensive. If you let the desktop handle this it scales nicely with all your desktops, but if you want the server to handle this it becomes a scalability nightmare.

Users need to select their printer. Showing a list with 5000 printers doesn’t help the user, he wants to search by location, by name, by department etc. Worse: showing 5000 printers and trying to show their status (as system-config-printer does) will eat 100% cpu.

Finally you need to configure the printers. How do you deal with 5000 printers on 50000 desktops?

If anybody has a good primer how to do such things with for example CUPS please leave a comment below!

Scale of the enterprise desktop – users, accounts, groups and permissions

Large corporations have many employees in many departments. And many of them will have an account. 16 bits for the UIDnumber is not big enough for some enterprises (but luckily the kernel handles 32bit numbers fine – but does your app?). All those employees in different projects and different departments means there are lots of different authorizations, meaning lots of groups, again possibly beyond the 16bit limit. And you may guess that the traditional scheme with owner/group/others might not do it – ACL’s are needed.

what does that mean for a GUI? For example a GUI to set file permissions:

• Ever thought of a dropdown with groups or users? Does that work with 50000 groups or 70000 users?
• Does it have a search field to select the right user/group?
• Does it display ACL’s in the GUI?

You can image that lots of users also means lots of users that forget their passwords. One solution to that is kerberos. Log on with your password, you receive a kerberos ticket, and you log on to every service using your kerberos ticket – never using your password again. Or better: logon using your PKI smartcard (with pkinit), you receive a kerberos ticket, and you never use a password at all! But this implies that all clients and all services support kerberos. The basics work well with Linux. Kerberos init on logon works and firefox understands it (so most internal web servers will work). But what about instant messaging (empathy?), voip and email clients? Lets make it worse: log on with dual factor authentication: a PKI smartcard with PIN code. Again the basics work, pkinit works perfectly on Linux, so you get a Kerberos ticket using your PKI smartcard. And even programs like gnome-screensaver can ask for your PIN code instead of a password. But GDM doesn’t understand it completely, you’re asked for a username while you enter your smartcard (that’s already passed with your certificate!). And your default gnome keyring won’t unlock anymore without a password (would be great if we could unlock it with the PKI certificate as well!).

• does your app work with Kerberos?
• will it work with dual factor authentication?

To manage a situation with this number of users, accounts and groups will be in a directory server, probably LDAP. In large enterprises all accounts are mostly in one level in the directory server. Smaller organizations sometimes try to organize accounts in their departments, but in large organizations there are so many people that move around to different departments, so many people that work in multiple departments, that they usually keep the departments as attributes in the account, and keep all accounts in one level. So what can go wrong. Image a ldap browser that lists all accounts per level: listing 50.000 of them won’t fir on your screen, and probably will take ages to load. You would think that most ldap browsers are designed for these situations, but they almost all suffer from this problem.

• can your app handle 50.000 results on a ldap query?

The good thing about the LDAP server is that all users have the same account on all systems, with the same permissions, same address, etc. So once you know the email address, you know their jabber and voip account as well. But oh: my email client knows how to look up names in a directory, but my jabber client doesn’t. And I cannot start a VOIP call from my email client – even if I know that the address is the same, I have to copy & paste it into another program.

• does your app support ldap directory lookups?

So there is some room for improvement here. And don’t get me wrong – I really like it that most things already work out of the box and how easy this is. It’s just the small things that could be improved.

The enterprise open source desktop – introduction

Many open source developers have never worked with large enterprise / corporate desktops. There are some important differences between a typical home or small business desktop and a enterprise / corporate desktop. Although there is noting wrong with that (you probably don’t like those desktops anyway), it might be good to know the differences, and use this knowledge when designing new software – and make it suitable for both the home and small business user and the large corporations. I’m not telling that open source is not good for them – I know there are workarounds for every item I’m going to mention – I’m only telling some things could be better!

Large enterprise corporations spend millions of dollars on desktops and have large IT operations, so they are a prime candidate for cost reduction using open source software. Enterprise corporations often see their desktop just as costs (and no benefits). The benefits are in the applications, being SAP, IBM Filenet, and the in-house developed application that has been there for 10 years already. If the open source desktop can present those most important applications this is a cost reduction without effect on the benefits – then we have a business case.

Anyway, I’ll try to do a series of posting about the most important characteristics of the enterprise desktop. Some points I will be talking about:

• scale – many users, many groups, many systems, many administrators, many departments and sub-departments
• security, authentication, authorization, lockdown
• consistency
• networking, latency, bandwidth
• support (costs), self-service