To content | To menu | To search

Tag - Linux

Entries feed - Comments feed

Tuesday 8 February 2011

Passwords are a broken system

..and I'm not even referring to the multitude of website passwords this time. I thought earlier OpenID would be the fix to those, but apparently not -- perhaps OAuth 2.0 and Facebook will be, though.

No, this time I'm talking of personal computer passwords. I don't have a huge amount of recent first-hand experience with how Mac and Windows work in this department, but the Linux/GNOME experience, connected to some presumably sensible company network access control, is certainly busted. Or, perhaps it's just me, and I'm doing something wrong - in which case, I would love to hear from someone who knows how to do this right.

I have:

  1. an encrypted home/user partition on my laptop hard drive, for which I have to type in a password to get the computer to boot. Never mind that the operating system partition (which doesn't contain anything secret, since the OS is downloaded off of Fedora Project's web site) isn't encrypted, so the computer ought to be able to boot without the user partition password -- it doesn't. That's a separate peeve. This is password #1.
  2. a password for my user account, since GNOME login facilities seriously under-appreciate using an account without a password. Never mind that I already proved who I am by typing in a password during boot - well, the last boot that was on average 19 days and 78 suspend-resume cycles and 42 laptop-bag trips ago. As far as I can tell, there is a valid reason for having this password, though I could imagine switching that to fingerpring recognition. Password #2.
  3. a password for the GNOME built-in passphrase storage keyring, which automatically collects things like network WPA passphrases, ... well, that's about it, really, but anyway, it makes life somewhat bearable. Password #3. In fact, all that stuff is actually stored in a keyring with a very long random string as a key, and a separate keyring holds a copy of that, locked using the password #2 -- when things work. This is what is supposed to let me type in a password once, and have the system usable.
  4. a password for my company account which lets me in to things like the intranet. One of many, many, many work-related passwords in various systems, internal and external (mostly external), which are infeasible to synchronize to one-time authentication at least today. This one is special though, because it's practically impossible to get any work done without it. Password #3 (I didn't count the one above, because it's not supposed to exist).
  5. a KeePass keyring pass phrase, because the GNOME keyring a) doesn't have decent UI so it could be used for manually managed passwords b) because of above, there are many of those c) that I need to also use on other devices, so this keyring is synced to those devices. Password #4, for those who are counting.

That's just the start, but without these, nothing works. Now -- password policy best practices often say that passwords must be changed periodically, in order to ensure various guarantees of dubious value. I ask you this - what happens, when one of the above passwords must be changed?

As good as my memory seems to be with random alphanumeric strings of letters and digits, I simply can not maintain four of them in memory along with the credit card PIN, phone number PIN, VPN token password, GMail password, Facebook password, and so on an so on, if I'm supposed to also get any work done. Especially not if one needs to be swapped out to a completely new random thing every now and then. So, I do what any human would do: try to minimize their number.

Because I'm relatively security conscious, I don't do that by using the name of my childhood pet on every system from the most security sensitive to every second web site that appears to require its own password. No, what I do is try to use the same password in all five of the above cases, because a) they're all needed in sequence anyway, b) I can't do effectively anything without access to all of them. I still need to type it way too many times, but at least that keeps the memory fresh.

Except -- changing any one of those places doesn't change any of the others. Not even the supposedly-integrated 1, 2 and 3. So, I end up with 5 instead of 1, and I don't know which is which. New "enter password to keyring 'default'" dialogs pop up on my desktop, prevent anything else from receiving any keyboard input, accept nothing as a valid password, and prevent me from working for 45 minutes. 

I did figure out how to solve it, though -- prevent GNOME Keyring from accessing the 'default' keyring (for which there is no typable password to begin with), force it to change its login password to the new login password, and then re-enable access to the main keyring with all the WLAN pass phrases and other assorted stuff. However, it still wasted a lot of time, and would probably have stumped anyone else I know (I'm pretty hard core with this crap, sad to say).

Broken? Yes. How to fix it? Hell if I know. Perhaps posting this rant would prompt the LazyWeb to point me in the right direction. Having to follow a 20-step routine to change one password isn't the fix, though.

Monday 23 November 2009

Notes about Fedora 12

Another six months, another Fedora release. Apparently I still couldn't resist the temptation of upgrading, given I got a few days of flu-related downtime. Happy to report it's a pretty smooth release, with most things in the expected places:

  • GNOME is a tiny bit cleaner than it used to be, which is as expected, given that's what it's been doing for the last 5 releases. Apparently next time it'll be something completely different. I don't know if I should be excited or apprehensive about that..
  • PulseAudio continues to improve - however, I could swear I've successfully used a Bluetooth headset with Skype earlier, and now audio gets stuck if I pair a headset. That's not the most typical use case, of course, and for the most part, audio no longer sucks on Linux. Too bad my laptop's built-in microphone does suck (don't know if that's with Linux or in general), so I do need a headset to make Skype calls.
  • Apparently Empathy is approaching a usable IM now that it's made the default. Still slightly prematurely, IMO, and I will continue to use Pidgin with all its warts for the time being.
  • OpenOffice still works as expected, which is to say, slowly, but reasonably predicably.
  • I can get rid of many of the hacks I've done to make multihead work as I like without setting it up every time, because now Xorg does that by default. Yippee!
  • Evolution still continues to gain one or two major regressions per release, and lose none of the earlier. The tally now seems to be: brken live search, fkdup IMAP sync, scrwy calendaring, and, as an additional feature, automatically selecting the wrong recipient address out of several available emails despite being repeatedly told otherwise. Seriously, the thing needs to be taken behind the shed and shot to the head. And I need to find a decent email program. Thunderbird 2 wasn't that - and 3 still isn't done. Sigh.
  • Google Chromium is about 10x faster than Firefox, and by far the easiest way to install a 32 bit browser (working Flash!) on a 64 bit OS (I should probably reinstall to 32 bits all around, this bits thing doesn't help me do anything better).
That concludes my "yes, I'm a Linux geek" postings for the next six months, I guess. :)

Thursday 15 January 2009

How to share a wireless connection with others using Ethernet and Fedora

It took me a bit of time to figure this out, and the Lazyweb wasn't too helpful this time, so a small note: If you have a wired Internet connection you want to share with others using your laptop's wireless adaptor, NetworkManager has a menu item for "Create a new wireless network". That's pretty obvious to find. However, if you want to do vice versa, and share a wireless Internet connection with someone connected over the wired Ethernet (or many people, if you have a small switch to share), the procedure is simple, but more hidden.

Continue reading...

Saturday 27 December 2008

A couple of Fedora 10 notes

For the last few Fedora Linux releases, I've been upgrading to a prerelease version a week or so before the actual release in anticipation of the real thing, and commenting here on what I saw. I did upgrade this time as well (a month ago), but skipped the commentary. A few belated notes, since this extended holiday gives me not just the time but also the itch to play with stuff. One big complaint, a few notable incremental improvements, and a few notes to self:

Starting with the complaint: Evolution, my long-time favorite desktop email application, has turned really annoying. Primarily because a rewrite of its on-disk message summary to use SQLite broke not just the one feature that converted me to an Evolution user in the first place ("vfolders", aka persistent, updating search folders), but every resemblance of a sensible mailbox behavior. It reorders messages in what might as well be a random order every time you delete one! Crazy. And peeking beneath the bonnet reveals that whoever wrote this doesn't have the first clue about how SQL-based relational structures work: every IMAP folder has its own table in the SQLite database with the exact same structure! Jeez, someone needs to read their database normalization guidelines again. I'm sorry, but not even free software gets to fuck up this badly. So, because downgrading to the last-good version (2.22) seemed like too much pain (given all the libraries it depends on were updated anyway), I switched to Thunderbird. I don't particularly like T-Bird, it's slow and clunky, but at least it doesn't block me from actually doing something with my email. Thank universe for IMAP and pretty good webmail apps (GMail and Zimbra) for making that switch smooth..

OpenOffice 3.0 was a very welcome upgrade, for the single reason that it supports OpenXML documents. Again, not really because I'd like to deal with 'OpenXML' documents, but because it's way more convenient to be able to deal with them than to try to make the few people who send those around understand that not everyone else in the world is in love with Office 2007.

Upgrade had a few scary gotchas. One which might hit quite a few people I saw a couple of weeks later upgrading another computer online with Anaconda: it would have been really smooth, save for the bit where the preupgrade program that downloaded F10 to a bootable image failed to pick a kernel package to the upgrade batch because F9's kernel was already at that time more recent than the F10 kernel. Once I figured out what caused that machine to crash during the reboot phase of the upgrade, it was easy to fix by downloading a kernel package into the upgrade batch manually, but the Python stack trace that showed up as would probably be unresolvable to 90% of Linux users, or 99.9% of the target population of most modern Linux distros -- never mind that Fedora and its bleeding-edge software probably still is a release for the more hacker minded.

The more scary gotcha hit me on my primary machine, though, one on which I've for a very, very long time used LVM snapshots as a backup and 'oops, that was a mistake, lets go back to yesterday' recovery facility by having two snapshots of the root filesystem available to me. This used to be fine, because Fedora was happy to refer to the FS by its LVM volume name, and because LVM's own bookkeeping facilities kept track of which volume is the "primary". However, as a throwback to a mistaken volume management feature from a few years back, F10 decided to convert all volumes to refer to each other via their filesystem UUIDs. Now, I agree that UUID (or the earlier convention of filesystem labels) reference is MUCH better that device names, given that disks may be plugged to different interfaces etc. However:

  1. LVM already had taken care of this and provides logical names for volumes that are independent of their underlying physical devices.
  2. Unlike LVM, the mount and fsck utilities apparently can't distinguish between the master volume and its snapshots, picking anything at random or everything at once.

The result: first, the machine failed to find a root filesystem at all. Getting that fixed, it would then proceed to crash in fsck because the snapshots were read-only. As far as I can tell at this point, I have three avenues available to myself: stop using snapshots as a backup facility (and go back to what?), manually fix the kernel init scripts and mount-points after every kernel upgrade (not such a big deal, except the kernel updates come every week or so), or become a Fedora developer and try to convince whoever came up with this idea that LVM had solved it already and it needs to be forgotten about. Given that I have this kind of time available for this stuff about once a year, I'm afraid I might end up giving up backups.

So, that's the complaints out of the way. Otherwise, F10 and GNOME 2.24 is another solid release, and aside of those rather bad glitches, the other stuff keeps on improving on the "make it just work" road. Now that zero-configuration X seems to pretty much work (see below), I'm curious to see where this kernel mode setting etc stuff develops to in the next six months.. Also, I finally had to learn how to use KVM and virt-manager because VMware Player broke in the upgrade. Had to give up copy-pasting between the host and the VM since I don't know of a working KVM-clipboard utility for Windows, but given how little I need virtual machines for (quickly testing some apps, primarily), that was no big loss to me.

And speaking of zero-conf X, one thing I finally got around to figure out was how to change the laptop's touchpad settings without having an xorg.conf: apparently it's done via an FDI file for HAL instead.

Wednesday 21 May 2008

Stop distracting wireless led blinking

While there's lots to like about my current laptop, one thing that had been quite annoying was the wireless indicator led. For a long time, it didn't function at all, because iwl4965 didn't contain support for driving it. Recently (effectively starting with Fedora 9 for me), that support came in, but now it's not annoying because you can't tell whether wireless is enabled, rather because the led is blinking all the time, which is a distraction.

I liked the behavior of my old laptop's ipw2200 much better: blink while searching/associating with a network, and then stay on constantly. Happily, Erich Schubert just pointed out how to fix the iwl4965 blinking behavior. That script is (I think) for Debian/Ubuntu, and a slightly different kind is needed on Fedora. I'm not sure this is the best way to go about it, but at least it works for me: put the following in /etc/NetworkManager/dispatcher.d/iwl-no-blink

if [ "$0" = "wlan0" ]; then
    for dir in /sys/class/leds/iwl-phy*X; do
        echo none > $dir/trigger

Monday 31 March 2008

Optimizing Linux for random I/O on hardware RAID

There's a relatively little known feature about Linux IO scheduling that has a pretty significant effect in large scale database deployments at least with MySQL that a recent article on MySQL Performance Blog prompted me to write about. This may have an effect on other databases and random I/O systems as well, but we've definitely seen it with MySQL 5.0 on RHEL 4 platform. I have not studied this on RHEL 5, and since the IO subsystem and the Completely Fair Queue scheduler that is default on RHEL kernels has received further tuning since, I can not say if it still exists.

Though I've heard YouTube discovered these same things, I have not yet seen a simple explanation of why this is so - so I'll take a shot at explaining it.

In short, a deployment with a RAID controller or external storage system visible to the operating system as a single block device will not reach its maximum performance under RHEL default settings, and can be easily coaxed about 20% higher on average random I/O (and significantly higher in spot benchmarks) with a single kernel parameter (elevator=noop) or equivalent runtime tuning via /sys/block/*/queue/scheduler in RHEL5, where you can also set this on a per-device basis.

We first saw this in 2005 on a quad-CPU server with a RAID controller connected to 10 SCSI disks. At that time, we found that configuring the RAID to expose five RAID-1 pairs which we then striped to a single volume using LVM increased performance despite making the OS and CPU do more work on I/O. The difference in performance was about 20%.

Our most recent proof of the same effect was a quad-CPU server connected to a NetApp storage system over FC. Since it was not convenient to expose multiple volumes from the NetApp to stripe them together, we searched for other solutions, and prompted by a presentation by the YouTube engineers looked at the I/O scheduling options and found a simple way to improve performance was to turn off I/O reordering by the kernel. Again, the overall impact between the settings was about 20%, though at times much greater.

The lesson is simple: reordering I/O requests multiple times provides no benefits, and reordering them too early will in fact be detrimental. Explaining why that is so is a bit involving, and is based on a few assumptions we have not bothered to verify, since the empirical results have supported our conclusions and got us where we wanted.

In order to keep the explanation simple, I will describe it conceptually on a very small scale. When reading this, please take this into account and understand that to measure the effect we have seen in practice, the size of the solution should be increased from what I am describing.

First, consider the case of direct-attached storage exposed to the Linux kernel as independent devices. In this configuration, the kernel maintains a per-device I/O queue, and the CFQ scheduler will reorder I/O requests to each device separately in order to maintain fair per-process balancing, low latency and high throughput. This is the configuration in which CFQ does a great job of maximizing performance, and works fairly well with any amount of spindles. As the application (a database in this case) fires random I/O, each of the spindles is executing them independently and serves requests as soon as they are issued. In other words, the system is good at keeping each of the I/O queues "hot". The sustained top I/O rate is roughly linear to the number of spindles, or with 15k rpm drives, about 1000 ops for four drives.

Now, lets introduce a hardware RAID of some sort, in particular one which is enabled to further reorder operations thanks to a "big" battery-backed up cache. Thanks to that cache, the RAID can commit thousands of write operations per second for fairly long periods (seconds), flushing them to disk after merging. On the other hand, the kernel now sees just one device, and has one I/O queue to it. The CFQ scheduler sits in front of this queue, reordering pending I/O requests. All is fine until the I/O pressure rises up to about what a single spindle can process on a sustained basis, or about 250 requests per second on those 15k drives. However, as soon as the queue starts building up, the CFQ scheduler kicks into action, and reorders the queue from random to sorted per block number (an oversimplification, but close enough).

All is good? No, it's not. The sequential blocks on that RAID volume are not truly sequential, but reside on different spindles and could thus be processed simultaneously. To demonstrate, lets assume your four-spindle array has one billion sectors or five hundred gigs per device, and further, that it is striped at 64k extents or 7.8 million stripes across each device.

On both configurations, the striping is essentially the same. Every 128 sectors or 64k is one one device, then the next one, and so on. The difference is that with LVM in place, the kernel knows this, while with the RAID, it has no idea of the layout of the array, essentially treating it as a single spindle.

Now, those couple of thousand request that were just issued, contain sequences such as writes to sectors 10, 200, 50, 300, 1020, 600, 1500 and 700. Due to the striping, four of these can be executed simultaneously, so the optimal order to issue these, of course depending on what else might be going on, is something like 10, 200, 300, 1500, 50, 700, 1020, and 600, executed through four queues: [10, 50, 600], [200, 700], [300] and [1020, 1500]. In the LVM configuration this might be what really happens. However, the single I/O queue to the RAID device will have these sorted into ascending block order, and with enough such operations in the queue, the RAID processor no longer has enough view to the queue to efficiently re-re-order them to utilize all the spindles, so only some of them are hot at any given time. TCQ should help, but in practice it won't issue enough outstanding requests to fix the problem. In our experience the top sustained rate is not more than 1.5 times one spindle, or 300-400 requests per second, while the array should really run at over the 1000 ops per second thanks to the additional persistent cache on the RAID controller.

Bottom line: CFQ is great, but only if the kernel actually knows everything about the physical layout of the media. It also looks like some of the recently introduced tuning parameters (which I know nothing about, just noted their appearance) might help avoid the worst hit. However, ultimately it doesn't matter - if your hardware allows efficient "outsourcing" of the I/O scheduling to a large secure cache, use it, and don't bother making the kernel do the job without all the information.

I hope this explanation makes sense, and that I haven't botched any important details or made wrong assumptions. Please comment if any of this is inaccurate.

PS. A tuning guide for Oracle recommends the deadline scheduler due to latency guarantees. We have not benchmarked that against noop.

Sunday 30 September 2007

Fedora 8 is looking good

Once again, I couldn't resist the urge to stay on the bleeding edge, so I went ahead and updated my home machine from F7 to F8 test 2. Encouraged by the results, I then (again) did the unthinkable and went through the same process on my laptop, which I depend on for getting stuff done. Crazy. Well, that's the way I like to play the game. And I wasn't quite THAT crazy - I didn't upgrade everything, just the parts that I was really happy about. Besides, I've set the laptop up with a whole-system snapshot LVM backup so that I can back up a day if things start to look bad.

They haven't. Apart from a few minor glitches (such as the Rawhide NetworkManager 0.7 really not being at all ready, dealt with by using the F8t2 NM 0.6.5 instead), I really like all the improvements in the usual suspects - GNOME 2.20 is a brilliant incremental update, OpenOffice 2.3 is a slight improvement on the already-improved 2.2 (but damn, are those release notes bad or what), the Power Manager is getting really good at predicting battery life, and (drumroll, please) Evolution has regained its stability! That is major. The "it seems to forgot to include an attachment you mention in the text" feature is a neat little improvement, too, but really, not having e-d-s crash on network events (such as resume in a new WLAN) is the real satisfaction-improvement for me.

One negative about F8: it doesn't include Seahorse 1.0 (as of yet, anyway), so GNOME Keyring integration was a bit lacking. That was easy enough to fix with a rebuilt package, and after switching the old pam_keyring to gnome-keyring-pam, I now have a very good package for dealing with my hundred-and-fourtyseven different daily passwords, too. Well, almost -- still can't really get rid of Revelation and some manual password management, and Epiphany doesn't yet integrate to Keyring. But it's getting there, for sure.

Friday 21 September 2007

MySQL Community vs Enterprise tension

I probably don't spend quite enough time following progress around MySQL considering how critical the product is to us. I'd like to consider it part of the infrastructure in a way I treat Red Hat Enterprise Linux, ie something I can trust to make good progress and follow up on a quarterly basis. Naturally we have people who watch both much more closely, but my time simply should, and pretty much is, spent doing something else.

However, it seems MySQL really demands a bit more attention right now. Today I went and read Jeremy Cole's opinion about MySQL Community (a failure), and I have to say I agree on many of the points. MySQL simply has not yet found a model that works as well as that of Red Hat's Fedora vs Enterprise Linux - that is, really giving the Community edition to the community to direct, and using the Enterprise edition as a platform for enterprises to depend on.

I feel the fundamental problem really is quite simple; as long as MySQL maintains the community edition (both binaries AND the source tree) themselves, and don't let the community integrate features to it on a timely basis, the model will not function, not even to their paying customers (us included). However, if they reverse this particular point from the current status-quo, all of the other benefits are inevitable.

The comparison to Fedora and RHEL is rather obvious, despite the distribution vs single product differences. Fedora is a great community Linux distribution with the latest-and-greatest features integrated to it on a very timely fashion. Not even Ubuntu can really compete with Fedora in terms of features. However, what Fedora gives up to reach this is a certain amount of polish and reliability. I will happily use Fedora as a personal platform, because of the latest features, but I would not pretend to run a stable system on top of it. For that, I'll rather choose something a bit more mature, that has proven itself in the community and received further QA ahead of commercial release. This is RHEL, and this is what the MySQL Enterprise should be. A version that, when it's released, I shouldn't have to hesitate to install on a new production server.

I also today learned about the Dorsal Source MySQL community release. Now this looks like something MySQL Community release probably should be like. I'll have to give it a test round and see what's up.

Update: Baron Schwartz describes a MySQL Enterprise that I would have far less trouble using than the existing one..

Wednesday 29 August 2007

Working 3D on the 965GM

I took a second (third, whatever) look at how to get 3D acceleration enabled with the TravelMate, and finally found the clue to avoiding a display lockup the moment an OpenGL application was started.

Fedora 7 will not support it as-is. You'll need at least kernel ( is now in updates) and Mesa 6.5.3. I found it easiest to install Richard Hughes' "Utopia" builds of mesa-libGL and libdrm and a rebuilt fc8 xorg-x11-drv-i810. With these three packages, DRI can now be enabled and the machine is stable. Performance isn't stellar, but it's plenty enough to enjoy compiz and a slightly blinged up desktop, which is essentially what I was looking for, anyway. Ready-made binary attached. Remember, you need to update the kernel and drm bits too with the linked stuff.

Tuesday 21 August 2007

Acer Crystal Eye and GStreamer

The Crystal Eye webcam in new Acer laptops, my TravelMate 6292 included, works with the linux-uvc driver, as I noted before. To use it in GStreamer applications, you need to have the v4l2src component, which recently moved from the gstreamer-plugins-bad collection to gstreamer-plugins-good. In Fedora 7, you must have g-p-g version 0.10.6, which was just released to updates-testing (in a few days in updates, I would expect).

Update: With Fedora 9 or 10, you need nothing extra: the default installs of gstreamer-plugins-good and kernel already have everything built-in. Just set your default video input to Video for Linux 2 in gstreamer-properties.

If you don't want to build linux-uvc yourself (it's very easy), you may want to enable the drpixel yum repo that has it pre-built for Fedora kernels.

rpm -ivh
yum --enablerepo=updates-testing --enablerepo=drpixel install gstreamer-plugins-good kmod-uvc

To test it, run:

gst-launch v4l2src queue-size=2 !  ffmpegcolorspace ! ximagesink

- page 1 of 4