Hassles with getting our NFS mount authentication working on Linux
Our existing Solaris NFS fileservers have a custom NFS mount authentication method to do relatively strong authentication of a machine's identity before we allow it to establish a NFS mount from us. For various reasons we've started looking at doing NFS service from Linux machines and so we need to implement some version of our NFS mount authentication for them (ideally one that looks exactly the same from the client side).
Our existing Solaris mechanism
uses a NSS netgroup module that does the authentication as part of
checking netgroup membership. Given that Linux has NSS modules and
/etc/nsswitch.conf and so on, I figured that this would be the
easiest and most natural way to implement our system on Linux.
Unfortunately this ran into the roadblock that you
can't write a NSS module that implements netgroups without using
internal glibc headers that define an internal glibc
your functions must manipulate. In effect you can't write NSS
netgroup modules at all.
(Since this is an internal header glibc is free to change the structure at any time and thereby make your existing compiled module silently binary incompatible.)
This leaves me trying to figure out the best alternate approach. Right now I can think of three:
mountditself, since we have the source code. The two drawbacks to this is that we have to figure out where (and how) to modify the
mountdsource and then we have to keep our hack up to date as new versions of
mountdare released. This implies we'd be replacing a standard Ubuntu or CentOS package with a local version, which doesn't make me really happy.
- Switch to IPSec for clients that need NFS mount authentication.
The obvious drawbacks are that this is likely to be (much) slower
and we have to get IPSec working, probably in its more complex form
- Use a firewall based mechanism to block access to the server's NFS and mountd daemons until a client has been authenticated (this might be a good use for ipsets). The drawback of this approach is that it requires the most custom software on the server and probably the client. I'd like some way to intercept mount requests, trigger our actions, and then let the mount request go on, but I don't know if that's even possible (or at least possible without deep netfilter hacks).
I plan to ask the linux-nfs mailing list if they have any clever ideas that I'm missing or any opinions on the best approach to do this, although I suspect that they'll tell me to use IPSec (it's the obvious solution apart from the performance hit).
The whole situation with glibc mis-managing NSS netgroup support irritates me. NSS is theoretically supposed to enable people to add their own modules but glibc has crippled this part of it for no good reason and made our life significantly more painful in the process. I'd report this as a bug to the glibc people except that the idea of reporting any 'features missing or misimplemented' issue to glibc is utterly laughable; not only would my problems not get solved any time soon even in the best case, but historically it has been an excellent way to get abused.
(While there are NSS modules outside of glibc I don't believe that any of them support netgroups, just things like users and groups and passwords. Not that glibc even really documents how to write those sorts of NSS modules either.)
What I'm worried about with retina displays on Linux
I've been waiting for high-DPI LCD panels to appear for years, so I'm both happy and excited to see 'retina' displays start to appear on desktop machines. Recent announcements even put a usable such panel within theoretical reach. But this means that I have to start worrying about one of the problems I may have with them, namely whether or not I'll be able to drive such a high-resolution panel under Linux.
Mac and Windows people don't really have any worries here. Since these panels are useless without the ability to drive them, there's going to be graphics cards that can do the job. By the time the market drives the panel prices down to less stratospheric levels, these cards should even be fairly widely available (although they may well still be relatively high end cards).
But I use Linux and I go further than that by insisting on using open source graphics drivers. The open source drivers almost always lag behind in both hardware support and feature support, while driving really high resolutions is likely to be a leading edge feature for quite a while. I can thus easily imagine a future where the only cards that can drive the high-DPI displays I want are high end ones that aren't supported in open source drivers and won't be for years to come.
(In fact the hardware that's best supported in open source drivers today seems to be Intel's, and who knows if Intel will even make a graphics chipset that can drive big high-DPI displays. So far all Intel chipsets have been integrated into motherboards, and people who buy systems with integrated graphics are often not seen as people with demanding graphics needs.)
By the way, there are of course a lot of software issues that are going to come up with really high DPI displays on Linux; many things work in absolute pixels (which are going to be tiny) and many graphics and icons won't be available large and won't scale up. I'm sure I'll be looking various tiny little pictures for years. But I also expect that all of those issues will get solved relatively fast, partly because they're also an issue on laptops with high-DPI displays.
(I suspect that some of them have already been solved in some desktop environments.)
PS: The current lot of 4K TVs are not useful for me as displays because they have too low a refresh rate. I've historically been quite sensitive to this issue with early LCD panels, so I'm basically sure that 30 Hz is not enough for my usage. Future 4K TV panels will probably improve that, but I'm holding out for high-DPI 5K displays since they've started to show up too.