Wandering Thoughts archives

2012-01-11

A Yum plugin I would like: using a local DVD as a repo source

It's become obvious to me that, to put it one way, Fedora 16 is where all of the update action is and Fedora 15 is not getting many changed packages (this is probably well known among people who actually pay attention to how Fedora is structured). This means that I really need to upgrade my home machine from Fedora 15 to Fedora 16. Because I'm sane I'll be doing this with a yum upgrade, which means that I need to get several gigabytes of all of those RPMs.

On my work machine, this is no particular problem because I have fast networking; I'm not going to notice fetching even gigabytes of data (and it goes basically as fast as the other end can feed it to me). At home, well, not entirely so much; I have a much better DSL downlink than I used to, but it is not really all that fast and I will definitely notice if it's in use.

What I would like to be able to do is use a local DVD as the source of as many of those packages as possible. The obvious DVD to use is the normal Fedora install DVD (hopefully most of the packages I need will be coming from the base Fedora 16 repository anyways instead of from the Fedora 16 updates). A plugin to do this would be useful for more than yum upgrades; among other things, you could also use it to easily add more packages after the upgrade (or after a from-scratch install from the DVD).

(This plugin would even be useful at work. Even though I do yum upgrades at work I often download the Fedora DVD image so that I can test in VMWare and do other things with it. It seems silly to download the same packages twice, once in a DVD image and once for a yum upgrade.)

While I think you can do this with a carefully created repos.d file, the plugin I'd really like would automatically notice things that look like mounted DVDs, check them for an install-DVD-like structure, figure out what Fedora version they're for, and create a repo on the fly as appropriate. This is probably a pipedream.

Using 'yum --downloadonly' overnight sidesteps a lot of the bandwidth issues for my specific case but it still feels like a wasted opportunity.

(I'd also like to be able to use a local DVD as a package source for mock's build environments. Repeatedly downloading base package sets every so often is not a really good use of my DSL link.)

PS: it's possible that what I want already exists and I just haven't found it. I think mock has some support for this, which I haven't investigated extensively as I don't often need to use mock at home.

YumLocalDVDs written at 22:43:12; Add Comment

How to use systemd to just run some stuff on boot

Suppose that you have some things that you want to get run when your system boots, much like rc.local. They aren't necessarily daemons, you don't want to wire them up to the whole systemd magic infrastructure, you just want to run something. Let us assume that you have some shell scripts for simplicity (if you don't, it's easy to convert what you need into one or more shell scripts).

When I was converting my old init.d stuff to systemd, here is how I did this:

[Unit]
Description=Run my stuff
After=network.target
Requires=network.target

[Service]
Type=oneshot
RemainAfterExit=True
ExecStart=/some/script
ExecStart=/some/other/script

[Install]
WantedBy=multi-user.target

(The systemd service that actually runs /etc/rc.d/rc.local is a bit different; see /lib/systemd/system/rc-local.service, at least on Fedora.)

If you want your rc.local equivalent to be started just as gettys and any graphical login manager are being started, it appears that you want to be after systemd-user-sessions.service. Most of the startup stuff I do doesn't need to be run that late but it does depend on networking being fully up so that the machine has an IP address and all its interfaces and so on.

(One of my wishlist items for systemd is the ability for services to depend on and be triggered on various sorts of network state changes. I suspect that the systemd people see this as more the job of NetworkManager and dbus in general, but NM is not something that I can use and I'd rather avoid having a second dependency and state change management system to handle dbus events when we already have a perfectly good general one in systemd.)

SystemdJustRunStuff written at 01:26:07; Add Comment


Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.