July 25, 2007
So during GUADEC I investigated autologin/followed by auto-locking the screen. The idea is a user may want to setup their machine such that they can turn it on, go get coffee, and come back to it all loaded (but locked).
One snag I ran into was that gnome-screensaver’s screensaver and the various components of the desktop (panel, splash screen, background, etc) would race to be on top of the window stack. The splash screen would pop up, then the screensaver would raise over it, then the panel would pop up and the screensaver would raise over it, etc. It was very flickery.
One solution to this is to use the MIT screensaver extension included with X. It provides a really-truely-always-on-top window that things like the splash screen and panel can’t ever raise over.
The screensaver extension has been rejected in the past for a few reasons:
1) We didn’t think we could get a fade in animation prelock since X maps the screensaver window automatically instead of letting gnome-screensaver do it
2) We didn’t think we could get separate screensavers running per head in a xinerama multihead setup since the screensaver extension only provides one window that covers the entire X screen (and so spans all the heads in xinerama setup)
3) We didn’t think X could reasonable know when the system was idle since there are more forms of user activity than input devices.
I wrote a little test program that demonstrates the first two issues are resolvable, and posted about it here:
The fix for the first issue is to use a None background pixmap on the screensaver window so that when it gets mapped the contents of the screen don’t get erased and we can fade from there.
The fix for the second issue is to run the screensavers on child windows of screensaver window instead of on the screensaver window itself.
June 29, 2007
So one of the the features I needed to implement for RHEL 5 was btmp logging for GDM. The btmp log is a record of failed log attempts that an admin can access by running the /usr/bin/lastb command. It’s similiar to the wtmp log which is a record of login and logouts by users, and also like the utmp log which is a record of users currently logged in.
GDM already had indirect support for those last two types of login records because when starting a session it would invoke the sessreg utility that ships with X. This utility would create an entry in the wtmp and utmp logs. This utility couldn’t create an entry in the btmp log, however, because it only gets invoked after a session is started, and the btmp log records failed login attempts–attempt that don’t lead to a session getting started.
The format of the 3 logs are nearly identical, so it made sense to do all the logging with in GDM. For RHEL 5, I pushed a patch that did wtmp and btmp logging, but neglected to do utmp logging. The reason for this was a bit of text in the utmp man page
xdm(8) should not create a utmp record, because there is no assigned terminal. Letting it create one will result in errors, such as ’finger: cannot stat /dev/machine.dom’. It should create wtmp entries, though, just like ftpd(8) does.
This turned out to be a mistake. People like to be able to see who is currently logged in by using the w command, which relies on utmp being up to date. I’ll be correcting that in a future RHEL 5 update.
Anyway, I submitted my patch upstream and Brian Cameron picked up the work and made it work in Solaris. This broke it in Linux, so he passed it back to me to fix for Linux.
There is still one issue left. utmp entries have a specific field per record called the ut_line field. For text logins you would put the name of the terminal device that is controlling the session. So if the user is logged in on vt 1, then the associated terminal device is /dev/tty1 and the ut_line field would be tty1.
For X logins, there is no controlling terminal, so there is some debate what should go in the ut_line field. Note, the warning I quoted above. Some utilities expect there to be a file in /dev with whatever value is given to ut_line. According to Brian, Solaris has traditionally dealt with this problem by creating fake files in /dev for each X login, just so programs like finger and w don’t freak out. These fake files are called “pseudo devices” and they’re sort of akin to pseudo-terminals, except they aren’t terminal devices.
Anyway, it’s not clear what we should do for ut_line. The whole idea of creating fake files just to satisfy some old unix utilities is sort of offensive, and it has SELinux implications as well. For RHEL 4, ut_line was not set to a valid file. It was simply the display number (:0 or whatever), so I’m thinking that’s probably the right way to go.
June 18, 2007
So one thing I wanted for my Graphical Boot stuff was a standalone environment for it to work in. I wanted it to have its own /proc, device nodes, etc, because it gets run so early in the boot process that those things aren’t set up yet globally. If I make my program set them up globally, then other parts of the boot process get confused that things are set up already. What I really want is my own private directory that only my process can see and that goes away when my process exits.
This is something you can do with individual files pretty easily. Something like:
char file ="/tmp/XXXXXX";
fd = mkstemp (file);
It turns out you can do something similar with directories, too, although there are some caveats. If your program
- creates a temp directory
- mounts a ram filesystem in the directory
- opens the directory and stores the file descriptor somewhere
- lazily unmounts the ram filesystem
- remove the temp directory
Then the directory will no longer be visible from the filesystem, but will exist as long as the stored file descriptor is opened. The program can fchdir() to the directory using the saved file descriptor and work with it. Now some of the caveats are:
- the program needs to be root to mount the filesystem
- MNT_DETACH (the mount flag used to lazily unmount a filesystem) is unsupported api
- you can’t mount other filesystems in your detached directory
Overall, it’s kind of a neat concept, but those caveats make it fairly impractical to use.
June 9, 2007
So mizmo booked our guadec tickets tonight. We’re flying out tuesday night and coming back monday.
June 9, 2007
So for RHEL 5, our moutainview team needed smart card login to work out of the box for DoD cac cards. I got asked to assist on the project, so I did the leg work to get gdm and gnome-screensaver responding to smart cards getting put in and pulled out. I also did a bit of work on the pam_pkcs11 pam module (Although that was mostly written by Bob Relyea of NSS fame).
Anyway, the bulk of the code was just cut-n-paste between gdm and gnome-screensaver. The longterm plan was to create a separate dbus service to do the actual talking to the card and have gdm and gnome-screensaver talk to the service . This is good because it reduces memory footprint, speeds up response time (which can be pretty slow with cac cards!), and means the card only has to get unlocked once instead of n times (which is an important feature if smartcard login is to ever become true single sign on). Anyway, RHEL5 came and we haven’t had time to implement the service.
Well, I got an email from boc the other day (well it was a few weeks ago), that he took my code and put it into a dbus service as part of work he’s doing for Novell! Awesome.
June 9, 2007
So Jon McCann of gnome-screensaver and ConsoleKit fame is doing awesome work on refactoring gdm to have a more modern structure to it. In particular, gdm will finally start using dbus to handle IPC instead of its own groady socket protocol. He’s also splitting up the code into coherent chunks and creating various gobjects to manage those chunks.
It’s a pretty huge undertaking but he’s making really good progress so far. He also landed some code that I wrote a year ago to rework the pam handling.
June 9, 2007
So gnome blogs now has a nice wordpress setup thanks to Jeff Waugh, so I thought I’d take the opportunity to maybe start blogging. I don’t know if I’ll keep it going–all my past attempts have failed pretty miserably.
Anyway, at work right now I’m working on trying to lay some of the ground work toward getting a prettier boot sequence for Fedora. We have a wiki page that covers an overview-y superset of what I’m currently working on.
Specifically, my goals right now are to
- get a graphical splash screen up quickly
- have it do something interesting for the entire boot sequence
- not show any text during bootup
- have all the text we show during bootup now, available in a file after bootup
- have a way for users to turn off graphical boot up easily
What we currently have in Fedora is RHGB. It’s a small program that gets started as soon as /usr is available during bootup. The program starts an X server, throws up a progress bar that updates as boot progresses and has a detailed view that shows a terminal window with all the mesages in the middle of the screen.
RHGB has a number of disadvantages:
- boot up stalls (for as much as 10 seconds or more!) until the X server is started
- it’s X server is different than the X server GDM uses
- this causes flicker from all the VT switching and mode changes when going from text mode to X to rhgb to text mode to X to gdm
- this triggers X driver bugs that have issues starting multiple X servers simultaneously or in quick succession
- the details mode is ugly
- boot messages aren’t logged
What I’m working on now has a subtle (although still somewhat unpolished) animation that fades the fedora logo in and out against a dark blue background. Rather than having a traditional progress bar or spinner, I randomly add a new twinkling star somewhere on the screen whenever there is boot progress. It’s just a off the wall idea I’m using for test purposes right now. The framework for displaying the animation is intended to be somewhat flexible, so that the animation is simple to write and can be changed out easily (somewhat analogous to a screensaver, I guess).
Boot progress is reported using the same interface that RHGB takes advantage of now. The init scripts manually call rhgb-client –update whenever something interesting happens and rhgb-client –quit when its time for the splash screen to go away. It may make sense to do something different on this front in the future, not sure.
Boot messages are trapped by creating a pseudo-terminal early on and redirecting the console to the pseudo-terminal. This happens before anything else is run (even /bin/init!), in the very top of the initial ramdisk. Changing the initrd over to use the interface is as easy as changing the shebang line at the top of /init from
and installing the binary and support libraries in the ram disk image. /bin/plymouth sets up the psuedoterminal and passes off to /bin/nash transparently.
The messages sent to the pseudo-terminal are buffered until the filesystem is fully mounted and then the buffer is dumped to /var/log/bootmessages.log
For development purposes I’m using the standard vesa framebuffer implementation that’s sitting in the kernel, but we probably won’t ever ship anything that uses that. It’s just not a reliable enough solution and it doesn’t really play well with X (which is important if we want to get nice transitions between booting to sitting at the login screen). Right now there are efforts by Jesse Barnes and a few other people underway to get a a reliable drm modesetting interface set up for intel video hardware. It’s likely that we’ll punt shipping anything until that stuff lands upstream.
Anyway, you can follow my progress at a git repository I set up here:
Well the last couple of weeks have been very fun.
The girl I mentioned previously, Mo, was an intern at Red Hat, but grad school was starting back up for her, so she had to move back to New York, which sorta sucks a lot. Yet, despite the fact that she moved back to New York last week, I saw her everyday except for yesterday last week. That’s right, she was either driving to my apartment in Nashua or from my apartment to New York everyday last week but yesterday. It was possible because this first week at her University was orientation (not classes) and so her schedule was really open.
Here’s a couple of pics of her:
She’s a very talented individual who is very skilled in Linux, Human Computer Interaction, artistic things, and Hello Kitty.
Let’s see, different topics….
I love Indian food. I eat it far too much now in fact. It doesn’t help that there is an Indian market store right down the street, and an insanely good Indian Restaurant a few miles away.
ummm…here’s a picture of me after my hair cut..kinda a junk picture though, cause my hair is wet and messy and i’m sorta unshaven…
Ummm, what else… I can’t really remember what’s happened lately.
Oh, car trouble…So Mo got a flat the other day (this was the night before the last day of her internship, the thursday night before last thursday), and she didn’t want to drive on the spare very much, so we parked her car and I drove her to work the next day. The plan was that I would drive her to her car after work and we would go down to a tire shop and get it replaced. The next day it rained hard….very, very hard, and when we got into my car after work and tried to start it–nothing. Just click…click…click… So we called a tow truck and had it towed to an auto shop down the road. Preliminary analysis suggested it was the starter that had gone bad. They were really busy though, and they are kind far away from where I live so the mechanic spent a few minutes to see if he could get it started so we could take it somewhere else more near my apartment. Sure enough, after about 100 turns of the key he got the thing to start! Damn, I just paid 60 bucks for towing. Ah well, at least it started.
So the plan was, I’d take Mo to her car, we’d pick it up and take both cars to the same shop near my apartment. Her’s was just a flat tire, so we’d get it back later that night, and mine would need a starter replaced, so it was going to have to stay into the weekend.
It didn’t turn out that way, however. Her bearings were bad, too, so it had to stay at the shop like my car. We just walked the mile or so to my apartment and on the way stopped at blockbuster to rent some videos. We crashed and in the morning we walked back to the auto center (it’s part of Sears actually) and guess what? My starter wasn’t bad at all, just a wire that went bad–presumably because of the harsh, harsh rain. What a weird twist of events, uh?
I took earlier today off work and went down to Boston with a friend. We got haircuts at a small shop ran by a couple of friendly Japanese guys named Fred and Steven. This is a bit of a big event for me because I’ve had long hair for so long that there was a lot of inertia stopping me from going shorter. I was ready for a change though, so I just told Steven to do whatever he thought would look good. I really like how it turned out.
On a different note, I also really like how my relationship with my friend is turning out. I feel really comfortable around her. We have a pretty close connection I think. We have a very open line of communication, and so we don’t play ambiguous manipulation games which are the norm in a boy-meets-girl world.
Well, I guess I’ll update again.
Let’s see… Last friday I saw a movie. I don’t remember what movie though. Before the movie I ate at an Italian restaraunt that I can’t remember the name of. I do remember the waiter was named Hugo. What was really interesting, though, was the table at the restaurant came with crayons and a paper table cloth. I spent most of the night creating a truly delightful scribbly mess next to someone who could really draw. My drawing looked so bad next the nice drawing, I decided I would just start doing random things to my drawing in a last ditch effort to salvage the image as abstract art…didn’t work. When it was all said and done with, my drawing had so much wax on it that it waterproofed the paper.
After the movie, at about 1am or so, we all went down to Nalin’s apartment in Saugus and fun’d for the night. On my way there I picked up some ice cream and frozen fruits, which we used to make beer floats and smoothies respectively. So we drank, and played Dance, Dance Revolution, and threw juggling balls at each other until about 6am or so, and then we went to IHOP for some breakfast.
After that, I crashed for the day and then in the evening time we went to a rowdy bar called Dicks, where the waitresses put hats with obscenities on your head and just be all around rude (it’s all in good fun mind you). By the end of the night the table had gone to war with each other in an all out paper and ice throwing fight. A friend of mine that I have been too flirty with recently, was wearing my fedora and keeping me stocked with plenty of ammo as I assaulted Nalin. Actually, most of the table attacked Nalin and he did a really good job of blocking the onslaught. Also, a chick from another table was downing shot glasses off perversely named mixed drinks off John’s … uhhh … lap.
Umm, on Monday I went to a concert with a couple of friends to see Alanis Morrisette and Bare Naked Ladies. I bought an overpriced tube of glowing color while there and spun it around a bunch to make really neat, semi-transparent discs in the night sky. It was expensive, but as some chick behind me pointed out to me, it was still cheaper than the beer I was drinking. The concert was actually a lot more fun than I anticipated. By the end of it, the Bare Naked Ladies were dancing around, synchronized with shopping carts.
umm on Wednesday (I think) I went over to Chris’s house and did the hookah thing again (my second time). Less luck making smoke rings this time. I also watched a funny movie that I can’t remember anything about right now strangely enough, and went dangerously overboard with the flirting with the friend.
I decided to work from home today in an effort to be more productive. It didn’t work. I got less done than I probably would have at the office. Oh well. I’ll just make it up this weekend. I guess one of the advantages of having a job I love is, I don’t mind doing it on my days off when needed!
But now, i’m going to go pick up a pizza and head to Chris’s house to play doom 3.