Life, with Technology
George Osborne, Chancellor of the Exchequer, has an exit strategy from politics. Rather than being employed as a consultant in the city, his career will revolve around making appearances and selling autographs at sci-fi conferences.
How do I know this? Read the credits for “The Force Awakens”. He’s mentioned there, unambiguously, as “George Osborne, Chancellor of the Exchequer”. It probably only appears on the UK release though.
If you have a domain name ending in .uk it’s probably administered by Nominet (exceptions being .gov.uk etc). Nominet is a not-for-profit outfit set up in 1996 to manage UK domain names as the Internet expanded. Unlike certain other countries, our domain registration service as traditionally operated for the benefit of Internet users, which is as it should be.
Right now Nominet is holding a public consultation on changes to the terms and conditions for anyone registering a domain name. It’s mostly sensible stuff, like dropping the need for a fax number. But there are a couple of changes that do worry me.
First off, there is a provision in the old terms that if Nominet changed the T+C of the contract once it had started, the owner of the domain could cancel and get a refund. This is only fair; people registering direct with Nominet could be paying hundreds of pounds in advance and you can’t change the rules of the game once it’s started without consequences.
The plan is to drop this provision, with the apparent stated justification that they can’t remember anyone ever invoking it. Lack of use doesn’t mean the provision is wrong; it simply means that they haven’t upset anyone with a change in T+C enough to make invoking it necessary. One likely reason for this is the requirement for a public consultation before changing the T+C’s.
The second problem is that they want to drop the need for a public consultation before changing T+C. This is all in line with “industry practices”, apparently.
Hang on Nominet, what have industry practices got to do with you? You’re not an industry; you’re a service run for the benefit of, and paid for, by Internet users in the UK. Other countries have domain registration services run on commercial lines, for the benefit of shareholders, and the last thing you should do is follow suit on their sharp practices. So why ask for permission to do so?
Nominet has been a beacon of how the Internet should be run, setting the highest standards in fairness and transparency. It should continue this way by setting an example of the highest standard.
Eroding the power of the stakeholders may be convenient from an operational point of view, and doing things properly may cost money (not something Nominet is short of). Dropping these awkward provisions may seem like a good idea at first glance. But for the sake of the wider picture, eroding the rights of domain owners would hardly be their finest hour. Unless, of course, the public consultation tells them to back off!
Here’s a link to the consultation. If you’re in the UK, your views count.
UNIX permissions can send you around the twist sometimes. You can set them up to do anything, not. Here’s a good case in point…
Imagine you have Samba set up to provide users with a home directory. This is a useful feature; if you log in to the server with the name “fred” you (and only you) will see a network share called “fred”, which contains the files in your UNIX/Linux home directory. This is great for knowledgeable computer types, but is it such a great idea for normal lusers? If you’re running IMAP email it’s going to expose your mail directory, .forward and a load of other files that Windoze users might delete on a whim, and really screw things up.
Is there a Samba option to share home directories but to leave certain subdirectories alone? No. Can you just change the ownership and permissions of the critical files to root and deny write access? No! (Because mail systems require such files to be owned by their user for security reasons). Can you use permission bits or even an ACL? Possibly, but you’ll go insane trying.
A bit of lateral thinking is called for here. Let’s start with the standard section in smb.conf for creating automatic shares for home directories:
[homes]
comment = Home Directories
browseable = no
writable = yes
The “homes” section is special – the name “homes” is reserved to make it so. Basically it auto-creates a share with a name matching the user when someone logs in, so that they can get to their home directory.
First off, you could make it non-writable (i.e. set writable = no). Not much use to use luser, but it does the job of stopping them deleting anything. If read-only access is good enough, it’s an option.
The next idea, if you want it to be useful, is to use the directive “hide dot files” in the definition. This basically returns files beginning in a ‘.’ as “hidden” to Windoze users, hiding the UNIX user configuration files and other stuff you don’t want deleted. Unfortunately the “mail” directory, containing all your loverly IMAP folders is still available for wonton destruction, but you can hide this too by renaming it .mail. All you then need to do is tell your mail server to use the new name. For example, in dovecot.conf, uncomment and edit the line thus:
mail_location = mbox:~/.mail/:INBOX=/var/mail/%u
(Note the ‘.’ added at the front of ~/mail/)
You then have to rename each of the user’s “mail” folders to “.mail”, restart dovecot and the job is done.
Except when you have lusers who have turned on the “Show Hidden Files” option in Windoze, of course. A surprising number seem to think this is a good idea. You could decide that hidden files allows advanced users control of their mail and configuration, and anyone messing with a hidden file can presumably be trusted to know what you’re doing. You could even mess with Windoze policies to stop them doing this (ha!). Or you may take the view that all lusers and dangerous and if there is a way to mess things up, they’ll find it and do it. In this case, here’s Plan B.
The trick is to know that the default path to shares in [homes] is ‘~’, but you can actually override this! For example:
[homes]
path = /usr/data/flubnutz
...
This maps users’ home directories in a single directory called ‘flubnutz’. This is not that useful, and I haven’t even bothered to try it myself. When it becomes interesting is when you can add a macro to the path name. %S is a good one to use because it’s the name as the user who has logged in (the service name). %u, likewise. You can then do stuff like:
[homes]
path = /usr/samba-files/%S
....
This stores the user’s home directory files in a completely different location, in a directory matching their name. If you prefer to keep the user’s account files together (like a sensible UNIX admin) you can use:
[homes]
comment = Home Directories
path = /usr/home/%S/samba-files
browseable = no
writable = yes<
As you can imagine, this stores their Windows home directory files in a sub-directory to their home directory; one which they can’t escape from. You have to create “~/samba-files” and give them ownership of it for this to work. If you don’t want to use the explicit path, %h/samba-files should do instead.
I’ve written a few scripts to create directories and set permissions, which I might add to this if anyone expresses an interest.