Older blog entries for skvidal (starting at number 418)

love

You know what I love?

When reboots don’t go horribly wrong.

Syndicated 2012-01-27 05:19:43 from journal/notes

fudcon day 2 and 3 thoughts

day 2 -
- running late – took brompton to get coffee and food
- barcamp, yay – gluster, once again, on top of my to-look-at-list
- lunch yay
- more barcamp
- head back to the hotel
- go to put the brompton back in the car – no keys
- retrace steps – no joy
- do it again – no joy
- resolve to not worry about it until sunday.
- fudpub. Nice – food was good, space was open, bowling seems to be a good activity for fedora-y people
- back to the hotel (while it snows) to sit around and talk for a long time. It was pleasant and worthy of note that sitting and talking with friends and coworkers is a nice way to take your mind off of other worries. I appreciated being able to sit and talk with so much of the infrastructure and other teams. It was comfortable and it was relaxing.

I guess that’s one of the F’s of Fedora.

Thanks to the organizers for putting this together.

Syndicated 2012-01-15 20:53:11 from journal/notes

fudcon day 1

a. infrastructure staging will perish:

1. Kill staging branch – identify what we want from staging to be in our ‘master’
branch.
a. copy staging branch to a subdir
b. kill staging branch
c. copy in pieces we care about a bit at a time – as needed.
2. move all .stg. boxes to ‘production’ puppet environment.
3. all boxes we maintain are ‘production’ from a configtest/pkging standpoing
4. app development moves to partial silos and/or openshift to do their code testing
then moved to production like a normal app deployment – rpm + config changes.

b. 2fa will start being implemented for users of sudo

c. if we are very good, smolt will find a new home. Maybe in openshift?

d. happy to meet pknirsch the guy in charge of the packaging team and hear of his evil plans to make my (and many other people’s) lives better.

Syndicated 2012-01-14 13:03:42 from journal/notes

copy if changed

I had written a bunch of versions of something like this for scripts over the years. Had to do it again, yesterday, and decided I’d do it ‘properly’ this time.

http://skvidal.fedorapeople.org/misc/copy_if_changed.py

It downloads from a url and copies to whatever you specify.

Summary:

copy_if_changed – copy file from a remote url to local destination. Return 0
if file has changed, 1 if it hasn’t and 2 if an error occurs

usage is: copy_if_changed url /some/local/destination

Really handy in shell scripts:


if copy_if_changed http://server/some/file /etc/some/file; then
run_something_here
fi


Other features:
- it makes a unique (timestamped) backup of the dest file before it copies it over.
- it uses sha256 for the checksumming

Not sure if it is useful to anyone else but I’m tired of rewriting the same thing.

Syndicated 2012-01-06 19:14:40 from journal/notes

puppet template ‘heredoc’

Using puppet? So sad.

Need to use puppet templates? Even worse.

Have to include a file, verbatim inside the resulting file but you don’t want to put it in your template itself b/c it is too big or cumbersome? Here’s how you do it.

 

1. put the file in the ‘files’ subdir in the module you’re working on in puppet

2. put this in your template

<%=
fn = Puppet::Module.find("test").file_directory + "/myfile.txt"
File.read(fn)
-%>


then that file will be read from the ‘files’ dir in your module directly into the output from the template.

Syndicated 2012-01-05 02:47:55 from journal/notes

performance issue reading in from an rpmdb

If you find all rpm and yum operations EXTREMELY slow – even doing  simple things like listing all installed pkgs – it would be handy to take a look at the numbers you’re getting.

A bug filed today:

https://bugzilla.redhat.com/show_bug.cgi?id=752897

 

has been able to replicate it.

 

However, if you would like to check it on your system in general please run:

time python -c ‘import yum; print len(yum.YumBase().rpmdb.simplePkgList())’

This will spit out a number and then some times. The times are obvious – the number is the total number of pkgs installed on your system  - according to your rpmdb.

If the time is beyond like 20s it’s way too slow. On my laptop it is between .12s and .78s.

Seriously – it shouldn’t take very long at all. if it is taking a long time – post your numbers in a comment on this blog post and what ver of rpm you’re using.

thanks

 

 

Syndicated 2011-11-10 21:10:51 from journal/notes

like chkconfig –list

reminder to me so I can find this later

for i in /lib/systemd/system/*.service; do svc=`basename $i`; stat=`systemctl is-enabled $svc`; echo -en “$svc\t\t$stat\n”; done

 

Syndicated 2011-11-04 21:25:42 from journal/notes

transition to f16 and other items

I spent a good bit of yesterday getting my system transitioned from f14ish/f15ish/mumble to f16rc4 from the xfce live install.

It took a while to get everything set up how I’m used to. I made the transition to claws from evo b/c I didn’t want to pull in the world with evo deps. I also transitioned some other tools around. One thing in particular though I kept was rhythmbox – I have a bunch of play lists in it and I didn’t feel like moving all those over to quodlibet.

However, rhythmbox has dropped rhythmbox-client for one reason or another and I use that quite a lot for the keys on my keyboard (fn-arrowkeys) which allow me to playpause/next/prev/stop whenever I need to. Trying to figure out how to fix that I ended up having to write this:

http://skvidal.fedorapeople.org/misc/rhythmbox-client

Not the most beautiful but it gets the job done. I tried introspecting the rhythmbox shell dbus interface but I couldn’t find a way to make music play/pause or anything so I gave up and when with the mpris one. It all felt a little silly.

anyway – you can bind those keys in the keyboard settings configuration in XFCE to that script with –next/–previous/–playpause

If there was another, simpler, way to do that google could not find it for me.

Syndicated 2011-11-03 16:46:59 from journal/notes

on pto – but about yum

I’m on PTO this week to get some downtime but I got to read the discussion about yum from the ticket I opened for fesco.

A few  things that seem to be widely misunderstood:

1. rpm does not have a depsolver. You can pass rpm a set of pkgs/hdrs and it can tell you if they are a complete transaction, if they have missing deps or if they conflict. It can’t tell you how to solve the problem – just that there IS a problem. rpm doesn’t know anything about repositories or configurations, plugins, etc. That’s ALL in the depsolver/package manager above rpm. In this case in yum.

2. librpm peforms the actual transaction. Yum mediates the transaction – it provides rpm with where the rpm pkgs are and provides a callback to tell the user what is going on. Yum also tries to track what is going on so that if something goes off the rails yum can try and recover.

3. When yum started out – it used rpm for everything. Yum was just a mechanism of indexing pkgs. It would take pkg headers, chuck them into a transaction set and ask rpm ‘tell us what is missing and we’ll find it’. That ate memory like there was no tomorrow and would not scale with many thousands of packages. I doubt yum 1.0 and 2.0 would be able to run, at all, with a modern number of pkgs like fedora currently has.

4. Yum was moved away from that partially by James Antill, Jeremy Katz, Paul Nasrat, Menno Smits, Tim Lauridisen, Florian Festi, Panu Matilenen and me.  The move away consisted of traversing the set of pkgs intended for the transaction (and their deps/provs) in yum itself and figuring out what deps were missing that way, rather than building up an rpm transaction set and asking rpm what was missing. Florian Festi and James Antill did an enormous amount of that work. It resulted in a speed up and gave yum more control over the depsolving process than was available before. Rpm was always used as a back-check at the end, though to confirm consistency.

5. For a very, very long time yum needed to use rpm-python for A LOT of things. From verchecking to just accessing the rpmdb. In recent time this dependence has been reduced. It has allowed faster access and simpler access (especially to the rpmdb).

6.  Every depsolver in the rpm-universe makes subtly different choices and therefore has potentially different results. Depsolvers deal with errors and issues in different ways. A lot of the behaviors people think of as yum-specific are adopted, originally, from the choices anaconda (and up2date) made in the Red Hat Linux days. (shortest-name-wins is an example of this). Yum made those choices as to remain consistent. Consistency in package dependency resolution is more important than other kinds of precision.   One of the reasons anaconda and other tools moved to using yum for their dependency resolution was specifically so we could have consistency across the board both at install-time and post-install. Consistency matters b/c at the end of the day the depsolver is impacting the files on a running system. The user/admin needs to be able to know that an action will return the same results on multiple systems – and that doing a transaction of pkgs post-install will result in the same thing as adding the pkgs in a kickstart %packages section.

Syndicated 2011-09-20 15:52:56 from journal/notes

2step auth for your gmail accounts

Been seeing a lot of random spam from known people on gmail accounts recently. People whose accounts got phished or brute-force-cracked or what-not.

I’d like to suggest folks using gmail look HARD at using this:

http://www.google.com/support/accounts/bin/static.py?page=guide.cs&guide=1056283&topic=1056284

it’s easy to setup and once you have it in place you’ve just made things much, much harder for folks to abuse. Not impossible, you’re not completely safe. But you are in a better position than you were before.

(caveat please don’t blame me b/c the guy in this video desperately needs to shave, it drove me nuts, too)

 

Syndicated 2011-06-08 17:15:03 from journal/notes