Rawhide notes from the trail: The thanksgiving edition

by on 2018/11/23 at 4:17 pm
Posted In: fedora, linux, rawhide

Sheesh, it’s been a while since I blogged anything again. I’m going to try and do at least 1-2 posts a week moving forward.

So, whats been happening in the rawhide world? Lets look back on this last month:

  • 2018-11-23 (today): dbus-broker switched to being the default dbus (A f29 change that didn’t make it and is planned for f30 now). Unfortunately, this broke anaconda as it launches it’s own bus and didn’t have the right package installed to do that anymore. This meant that everything that well… installed did not work. Adamw quickly submitted a PR and new fixed build and another rawhide is running now.
  • 2018-11-22: dnf maintainers were updating the dnf stack of things and happened to be in the middle of that when rawhide compose started, this meant that everything had broken buildroots and failed to compose. As a reminder, rawhide composes start at 05:15 UTC every day. Please avoid breaking things right before that.
  • 2018-11-21: finished (incomplete)
  • 2018-11-20: finished (incomplete)
  • 2018-11-19: finished (incomplete)
  • 2018-11-18: finished (incomplete)
  • 2018-11-17: finished (incomplete)
  • 2018-11-16 and 2018-11-15: The 14th compose got stuck, so the 15th never happened.
  • 2018-11-14: A change in an ostree file meant that pungi didn’t properly emit a fedmsg so the ostree could be signed. So, it got stuck there waiting. A fix was attempted, but (my mistake) not applied correctly (I didn’t update pungi on the composer after I built a patched one).
  • 2018-11-13: failed due to libreoffice deps being broken and the workstation live thus not building.
  • 2018-11-12: finished (incomplete)
  • 2018-11-11: finished (incomplete)
  • 2018-11:10: finished (incomplete)
  • 2018-11-09: finished (incomplete)
  • 2018-11-08: failed due to pungi-gather segfaults. This has proven very difficult to track down. In case it was memory related (and because we had more memory handy) I increased the rawhide composers memory by a ton. It seems to avoid the issue now at least since we haven’t seen this since this day.
  • 2018-11-07: failed due to pungi-gather segfaults.
  • 2018-11-06: failed due to pungi-gather segfaults.
  • 2018-11-05: finished (incomplete)
  • 2018-11-04: failed due to broken kde deps
  • 2018-11-03: failed due to two issues: 1) aarch64 had a issue with networking that caused the aarch64 cloud image to fail and 2) there was a weird issue with python3 and anaconda.
  • 2018-11-02: failed (see 11-03)
  • 2018-11:01: failed (see 11-03)

Most of the more anoying failures would have been blocked if we had gating in place (no broken deps would have crept in and if we tried a base image with anaconda/python/etc we would have found the breakage there eariler). I sure hope we can get that in place someday. 🙂

Comments Off on Rawhide notes from the trail: The thanksgiving edition

A short note about posting links to facebook

by on 2018/09/28 at 5:57 pm
Posted In: fedora, linux

Just a short note to everyone out there that posts links to facebook pages or posts: Something you may not realize is that for those of us that do not have or want to use a facebook account the experience is pretty subpar.

You go to the page (without being logged in to facebook) and the page or post loads, you start to read it and then… BAM a gigantic popup appears, blocking all the page contents. It’s a dialog asking you to login to facebook or create a new account or (in small print on the bottom: “Not now”). So, not wanting to login (for whatever reasons), you click on ‘Not Now’. The dialog disappears… but is replaced by a wide bar on the bottom of the page asking you to login or create a new account. Thee is no close button on this bar, and it blocks about the bottom 25% of the content, so you get to page up and down and try and read around it.

I know all the reasons facebook is doing things this way, but I just wanted to mention it to those of you who do login to facebook and perhaps didn’t even know about this.

So, do think, next time you share a link, is there some more free place to share it?

Comments Off on A short note about posting links to facebook

backups⁉️

by on 2018/09/03 at 4:27 pm
Posted In: fedora, linux

A nice long weekend (in the US at least) is a great time to deal with your Backups. You do have backups right? They work right?

For a number of years now I have been using rdiff-backup for my backups. Unfortunately, a week or so before flock my backups started erroring out and I put off looking into it for various reasons until now. rdiff-backup has a lot going for it, but these days it also has a lot against it:

  • It’s in python2 with no python3 support, and as we all know, python2 is going away before too long.
  • There’s not really any upstream development. A few years ago development was handed off to new team, but they haven’t really been very active either.
  • No encryption/compression support
  • slow, especially when you have a lot of snapshots.

So, I decided it was time to look over the current crop of backup programs and see what was available. My critera, which may be very different from yours:

  • Packaged in Fedora (bonus points for epel also. I don’t have any RHEL/CentOS boxes at home, but I’d like to be able to use whatever I find in Fedora Infrastructure too, where we are also using rdiff-backup).
  • Encryption/Compression support.
  • Active and responsive upstream

I went and looked at: BackupPC, zbackup, borgbackup, burp, bacula, obnam, amanda, restic, duplicy, and bup. (and possibly others I didn’t remember). From those I narrowed things down to restic and borgbackup. Both have very active upstreams are packaged in Fedora, but retic doesn’t have compression support yet (its written in go and they are waiting for a native implementation). Also restic isn’t (yet) packaged in EPEL.

So, with that I took a closer look at borgbackup. Upstream is quite active, there’s various encryption and compression support. You can store an encryption key in the repository or outside and use zlib, lz4, or lzma compression. There is a interesting ‘append-only mode’, so you can set that in the ssh key a particular client uses to conact your backup server and then that client can only append, not delete any backup data, which might be nice if you are backing up a bunch of clients to the same repository (and thus getting the deduplication savings), of course you can only run one backup at a time on the same repository, so you would need to spread them out or keep them retrying or something.Likely not a big deal for my home network as I only have the laptop, and a main server to backup here, but in larger setups could be a problem.

So, after a bit of cleanup on my laptop (I had some old copies of emails in several places, photos in a few places, junk I no longer needed/wanted, etc), I fired off a initial borg backup to my storage server. It’s still running now, but it seems to be going along pretty nicely. As soon as I have a full backup, I’ll try a restore of a few random files to make sure all is well.The final part of my backups is moving the backups from my storage server ‘off site’. In past years I copied my backups to an encrypted external drive and gave it to a friend to store, but I don’t have such a local person here, so I will need to investigate amazon glacier or other options, look for another post on that soon!

If you are reading this, perhaps you could take a minute to think about your backups, make sure they exist, are running ok and work.

Comments Off on backups⁉️

Flock 2018: The journey home

by on 2018/08/14 at 12:46 pm
Posted In: fedora, flock, linux

I decided to take a slightly different way home. In part because I couldn’t find a flight from DRS -> AMS that would get me there in time for the AMS->PDX leg and partly just because it would be fun:

I took the train from dresden to frankfort and then on to Utrecht. It was about a 10 hour journey, but it was nice. I went with Patrick and Randy and we had a bunch of discussions and watched the landscape go by. In Utrecht I got a hotel for overnight and we went to a great little resturant along the canal. Great place. My only regret it that it got too late for me to see Patrick’s place, so I just went to bed and got up the next morning for my flight.

On checking in I saw that I had a lovely SSSS on my pass, so I got to get extra searched at the gate, but it wasn’t too bad, and it let me board before I would have normally been able to. Then the flight back and the drive home were mostly uneventfull and I managed to get in around 2pm.

Overall this was a great flock, I had a lovely time and all the organizers did a awesome job!

Comments Off on Flock 2018: The journey home

Flock 2018: Day 4

by on 2018/08/14 at 12:40 pm
Posted In: fedora, flock, linux

The last day came nice and early right into sessions. However, I instead gathered with a few folks to distribute some keys for various things so we were sure that if someone won the lottery and left we would be able to have access.

The next session I went to was Randy Barlow and Patrick Uiterwijk’s Openshift session. Not much I didn’t already know, but some good discussion and questions from the audience.

After that was group photo (many people already suggested we do this on the first or second day so some people haven’t left yet), then council wrap up.

After things wrapped up, some of us stayed at the hotel visiting and hanging out and saying goodbye. Until next year flock!

Comments Off on Flock 2018: Day 4