Why developers suck as admins

So Fedora 12 allows regular users to install packages as long as a) the user is logged in on the console, and b) they are signed and from a trusted repository.

I think it's great that we can enable this functionality, and I'd even argue that it should be on by default on the Live spins (and installs from the Live spins), but in the general case this is a horrible idea.

I've seen a few arguments why this doesn't matter. For example, anyone with local console access already owns the box, right? Well, console access != physical access. Think, well, anything in a server room (systems in locked cabinets attached to a KVM, or virtual machines). While this gives more ammo to us old-timers for not putting X on our servers (I'm looking at you, skvidal), the reality is that it's not realistic to expect all servers to run without a GUI.

I don't want to re-hash the whole (long) thread linked to above, but I think it is important to point out some of the solid reasons why this change is a bad idea.

• The installation of one package shouldn't change the behavior of the system. (This one package changes the behavior of the system, plus allows for other packages to be installed that could do the same.) If you take into account that unintended dependencies tend to pull in random stuff during upgrades, this becomes especially important.
• Can we really guarantee that there are no signed packages available that are exploitable, all the time?
• This is a major change in behavior from Fedora 11 that did not go through the Feature Process, unless I'm missing something.
• Possibly even worse, if this "feature" makes it into RHEL 6, you run the risk of a lot of semi- and non-technical sysadmins having yet another security decision made for them, probably without their knowledge. (How many are aware of ctrl-alt-del, console users being able to shutdown/reboot, grub allowing kernel options ("single", for example) unless you set a password, etc.? Of course I've never understood the logic of all of that being open, but magic sysrq being off by default.)
• At the very least, this is a DoS attack vector, although more likely due to somebody screwing up and installing a bunch of packages rather than somebody intentionally trying to fill /, /usr, or /var.

Oh, and about the title... Developers of software get stuck into a mindset of "make my software work, no matter what", and, on a related note, tend to have tunnel vision about the use cases for their software. One of the things I love about Fedora is that we have a lot of sysadmins who happen to be coders, so we tend to find a good balance between "usability" (AKA letting the developers go nuts) and maintenance/security. This one slipped by us, but I hope the decision will be made to push an update with a more sane default. [Update: It was.]

Ohio LinuxFest 2009

So I'm trying to prepare for the 7-hour commute to OLF on Thursday and Friday's class. It should be fun, as always...

If anyone reading this is within driving distance (which, in my mind, includes most people in the eastern half of the US), I highly recommend making the trip. And they extended the registration deadline to midnight tonight (9/22), if I'm reading the site correctly...

Note for amavisd-new users

I just pushed amavisd-new 2.6.4 to rawhide. The major new change in this version is the introduction of a script called amavisd-snmp-subagent. To quote the release notes...

- newly supplied with the package is a program amavisd-snmp-subagent,
 acting as a SNMP AgentX, exporting amavisd statistical counters database
 (snmp.db) as well as a child process status database (nanny.db) to a
 SNMP daemon supporting the AgentX protocol (RFC 2741), such a NET-SNMP.

 It is similar to combined existing utility programs amavisd-agent
 and amavisd-nanny, but instead of writing results as text to stdout,
 it exports data to a SNMP server running on a host (same or remote),
 making them available to SNMP clients (such a Cacti or mrtg) for
 monitoring or alerting purposes.

See the release notes for more details.

Since this script introduces new dependencies, I made a sub-package for it, which includes an init script. All of this is completely untested, so if anyone would like to try it out, please grab it from rawhide (or koji until it shows up there) and let me know how it goes.

Hey, spot!

After reading spot's post, I wanted to try out chromium. Shortly after installing it, I realized that name resolution stopped working.

The problem? Installing chromium.i586 pulled in nss-mdns.i586 on my x86_64 system. I installed nss-mdns.x86_64 and the problem went away.

Whee!

Want to use chromium on x86_64? Do this:

cat > /etc/yum.repos.d/chromium.repo <<'END'
[chromium]
name=Chromium Test Packages
baseurl=http://spot.fedorapeople.org/chromium/F$releasever/
enabled=0
gpgcheck=0
END

yum --enablerepo=chromium install chromium nss-mdns.x86_64

Can a phone change your life?

To answer my own question, probably not. I did however get a Palm Pre when they came out (just over a month ago), and so far I like it. I was replacing a craptastic LG flip phone, so my smartphone expectations were rather low.

Here's what I like:

• Real web browser! (Usable on EVDO, but much better on Wi-Fi.)
  
• Camera that takes decent pictures.
• Some usable PDA functionality.
• Notifications add to the experience of using the phone instead of just being obnoxious.
• The "Sprint Navigation" app means I don't need to fight Kara for the TomTom. :-) (It's not as good as the TomTom, but it works well enough.)
  
• And, of course, bonus geek points for running Linux under the hood.
  

I don't know that I have any "issues" with the Pre, but I do have a short wish list...

• My old phone would let me forward text messages and send messages to multiple recipients. I miss that. Supposedly it's coming in a future update.
• The Clock app on the Pre is infinitely better than the one on my old phone, but my old phone would let me set a "quick alarm" for 1 minute, 10 minutes, 30 minutes, or 1 hour in the future. That was handy, if not nearly granular enough. A quick way to set alarms as an offset from now would be handy for a lot of reasons though.
  
• Admittedly, I'd kill for a terminal. :-) (And on that note, I may have to try out WebShell.) In general, I do have a little iPhone/Android app envy, but that should get better with time...

I can't say I'm completely thrilled with putting my information out "in the cloud", but Google already knows so much about me it is disturbing, so what the hell...

I don't know what I would do without Google and bugzilla.

Eric Sandeen is my new favorite person.

I'm finally watching a Fedora 11-based custom live CD boot...

Shiny

I love this effect.



I highly recommend perusing the gallery. Kara has some great stuff (although I think this is the only Fedora-related photo, and it was a happy accident).

ldapsync

Very slowly catching up...

A few years ago, I wrote a script that I called ldapsync that compares and synchronizes two LDAP servers. The options are designed to mirror the ones used by OpenLDAP's tools.

Usage:
    ldapsync [options]

     Options:
       --simpleauth -x      Use simple authentication (default)
       --binddn     -D      Secify the Distinguished Name to bind to LDAP
       --secret     -w      Specify the password
       --secretfile -y      Specify a file to read for a password
       --ldapuri    -H      Specify the URI of the LDAP server
       --searchbase -b      Specify search base
       --filter     -F      Search filter
       --scope      -s      Search scope (base, one, or sub)
       --tls        -Z[Z]   Try StartTLS (use twice to require TLS)
       --dryrun     -n      Show what changes would be made
       --help       -h      Help message
       --verbose    -v      Be more verbose
       --debug      -d      Turn on debugging

So to compare server1 with server2, you might use a command like this:

    ldapsync -n -x -b dc=example,dc=com \
            -H ldap://server1 \
            -H ldap://server2

Reality is probably a lot more complicated than that, but you get the idea...

Anyway, the script is useful as-is, but it is probably not complete. Maybe it will be useful to someone else...

Help!

My life has apparently hit a point where finding 5 minutes for anything is next to impossible. I seem to need to be in no less than 4 places at any given time. My contributions to Fedora are suffering as a result.

I really, really hope this is a temporary(-ish) situation, so I'd rather not orphan my packages (but I will if it is for the best). In the mean time though, I need some help, bad. It's been a couple of releases since I've been able to look at any of my non-Perl-related packages seriously, especially the GUI stuff. Luckily most of them don't need updates often, but right now I'm being harassed in bugzilla about font guidelines.

If any of you generous Fedora folk would happen to have some free time to bail me out and take care of that (or any other bugs I've forgotten about), I will forever be in your debt.