Just another quick note that rawhide kernels are back to booting and working normally here at least. With 4.9.0-0.rc0.git3.2.fc26.x86_64 at least. That should be in today's rawhide.

Just a quick note that with the upstream kernel folks opening up the merge window for the 4.9 linux kernel, rawhide also has been getting these merge kernels. Of course there's a ton of churn when the kernel merge window is open, vast amounts of things are merged, so it's a wonder they usually work as well as they do. In this case there seems to be some pretty severe issues with at least kernel-4.9.0-0.rc0.git1.1.fc26 and kernel-4.9.0-0.rc0.git2.1.fc26 at least. In vm's they seem to boot and then start oopsing. On my laptop it does boot, but then waits about 2 minutes at waiting for usb devices, boots the rest of the way up and then has no wireless or usb devices. https://bugzilla.redhat.com/1382134 is tracking at least part of this issue and the kernel maintainers are digging into it. Of course while they are, more things are being merged (possibly even fixes to these issues), so hopefully it will all shake out in the next few days. In the mean time, rawhide users are advised to just switch back to the 4.8.0 final kernel for now.

Akin to locking your doors and closing your windows there's some really basic things everyone should be doing with their Linux installs (This is of course written from a Fedora viewpoint, but I think this pretty much applies to all computer OSes).

1. Choose nice long passphrases you can remember. Most any modern system will have a pretty long limit on passphrases, so pick something nice and long that you can remember. Don't think of them as passwords, they are phrases with many words.
2. When installing, encrypt your drive(s). The performance hit is not noticeable and if you ever throw away a broken drive or someone steals your computer they won't have your data.
3. Apply updates regularly. If you aren't someone who remembers to do so, setup something like dnf-automatic to just apply them every day for you in the middle of the night. Otherwise try and get into the habit of letting gnome-software do offline updates at some regular time.
4. Along with (3), reboot when needed for new kernels or glibc or other things you use. Get used to rebooting on a regular schedule. Don't be afraid of rebooting, get used to doing it.
5. If you are in a place with untrusted people roaming around, do setup a screen locker and lock your computer when you are away from it.
6. Make (and sometimes test) regular backups. You may not think of backups as a security measure, but they sure are. Think of the new fad of 'ransomware' where someone encrypts your data and sells you the key. If you have good backups you can just wipe that all out and restore from those. They are handy for lots of other reasons too.
7. Don't open weird attachments or links sent to you in email. If you didn't ask for it, delete it.
8. Don't plugin weird devices you run across to your machine. (USB or otherwise). You can use a neat package called 'usbguard' to make sure no one else does while you are not around too.
9. Use a passphrase manager or have some system to allow you to have long, not easily guessed passphrases at all the various applications you login to. There's tons of these out there: Password managers: pass, keepassx, gpg encrypted file, etc. Schemes: Diceware, etc. Pick one that works for you.
10. If you use a laptop/travel a lot, consider using a VPN for all your network needs. As long as you have an endpoint to connect to (your home server, your work, a vpn provider) you can send (almost) all your traffic over the vpn and thus avoid problems with people sniffing local traffic.

Some of these things require an initial investment of time (backups, vpn, passphrase manager, screen lock) and some require just making something a habit (long passphrases, apply updates regularly, reboot regularly, don't open weird things in email or the physical world), but they are all worth it. Will this make your computer "secure"? No. There's no such thing. "secure" is not a binary state, it's a process of assessing threats and deciding what you can or want to do about them. Doing the above things will protect you from some threats nicely (guessable passwords, untrusted people tampering with your computer, sniffing traffic, vulnerabilities that have already been fixed in software you use, etc), but will basically do nothing against others ( someone installing a keylogging device and recording everything you type, someone threatening you with harm to tell them some information, someone installing a spy cam and recording everything on your computer screen, someone using a non public vulnerability in software you use, someone social engineering access to your computer, etc).

Just a quick note for everyone who gets emails from fedoraproject.org or it's various other domains. Just before we entered freeze for Fedora 25 Beta we landed changes to make our smtp servers use TLS where possible, so emails to servers that support it should now be fully encrypted. Please let us know if you see any issues related to this change.

From time to time rawhide composes fail and are not announced or synced to mirrors. In the past this would happen only if the very basic setup (a mock chroot with the 'buildsys-build' group installed in it) broke. Additionally, in the past rawhide composes where many deliverables failed to compose were still synced out and announced, leading to days when no images were available until the issue was fixed. Now, with the latest version of pungi (The tool that composes Fedora releases, including rawhide), composes can fail if some deliverables (Those marked in the configuration as not failable) didn't complete. So, while rawhide can fail more easily, it also means it's much easier to revert some change that broke images and get that fixed before it lands, and images should be always available. So, how can you tell if a rawhide compose (or some part of it) failed and why? All the pungi logs are avilable and since all the builds take place in koji, anyone can look at them as well. Rawhide composes are of course fedmsg enabled, so you want to look for the https://apps.fedoraproject.org/datagrepper/raw?topic=org.fedoraproject.prod.pungi.compose.status.change topic. Composes can finish with 3 states:

1. FINISHED - This means the compose finished and everything in it completed successfully. I am not sure we have yet seen this status in real life. ;)
2. FINISHED_INCOMPLETE - This means the compose finished and only failable things failed. This is the "normal" status we see day to day.
3. DOOMED - This means the compose failed it's initial very basic setup and/or some deliverable marked as not failable failed. When this happens, it means the compose isn't synced out or advertised. This is the status where we need to find out what caused the problem and fix it and either restart the compose or wait for the next days compose. In IRC or on fedmsg you may see this status as "failed in a horrible fire" as thats what our fedmsg translates it to.

So if you have a compose and you want to see why some part of it failed, you can look at the fedmsg and it provides a location url, but they are always the same format. Lets look at an example: https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20161002.n.0/ This means it's a rawhide compose (there's a Branched directory for the Branched Fedora 25 right now), then the particular compose was Fedora-Rawhide-YYYYMMDD.n.0. Yeah, month and day, then a 'n' to mean 'nightly' and a '0' to mean it was the first compose of the day. If there's more composes that same day, they are in n.1, n.2, etc. For Alpha/Beta/Final releases there's no 'n' there, as they are not nightly. The first place I go to look for issues is the global log file. This would be in logs/global/pungi.global.log and you will want to look for the image or deliverable you are interested in or search generally for tracebacks. Usually this will note a koji task id or build which you can then look up on koji. Since this is already getting long, I'll post about tracking down koji build problems another day.

It's once again been a while since one of these posts, but again I'm going to try and do them more often again. This last week had a few big changes in rawhide:

• With the Fedora 26 change approval last week ( https://fedoraproject.org/wiki/Changes/DNF-2.0 ) DNF-2.0 has landed in rawhide. Things were a bit shaky at first as the compose tools were not also updated, but anaconda folks were ready with a patch and lorax got a patch from the DNF maintainers and everything landed. There's still one big issue outstanding: dnf 2.0 sets strict group installs back to true, which causes all the live media to fail to compose. Some of our comps groups contain packages that only exist in some arches, not all of them, and when dnf does strict group installs it errors when it cannot find all the packages in the group. I've filed a bug for figuring this out: https://bugzilla.redhat.com/show_bug.cgi?id=1380945
• Last year we setup a quick and dirty autosigning setup for rawhide, which was just a script in a loop run by releng folks when they remembered to do so. This meant it wasn't all that reliable. Now, thanks to Patrick Uiterwijk, we have a real autosigning setup implemented and are very very close to an always signed rawhide. The final bit of gating needs a update to fedpkg to go out first, but as of last week, most everything should be signed with only the rare issue with a build that lands right before the compose starts.
• There has been some work the last few weeks to produce a rpm ostree for rawhide that is updated every few minutes. Once this is available it will be a great help to testing and running rawhide.
• Xorg server 1.19 almost landed, but we need to fix tigervnc before it can (at least without breaking all the install paths for rawhide). That is being fixed in a side tag and should land as soon as tigervnc is fixed. https://bugzilla.redhat.com/show_bug.cgi?id=1380879 is tracking that work
• A while back changes were made to cause composes that fail when some deliverables don't compose. This has been very helpful in making sure changes that land don't break things. New package builds that cause the entire compose to fail can be untagged until the breakage is fixed.

That's it for now from the rawhide trail...

disSome of you may have seen this post last week: https://www.agwa.name/blog/post/how_to_crash_systemd_in_one_tweet I saw it I think shortly after it was posted to hacker news (aside: I read hacker news via it's rss feed that has just the raw links and no comments or ratings, much nicer IMHO). My first thought on reading it was "Did they report this upstream?" and upon some digging, yes they did ( https://github.com/systemd/systemd/issues/4234 ). It was filed the same time they posted their blog post/tweet (no responsible disclosure here). My next thought was to see if it worked, so I tried it on various of my test machines and it did not. Turns out you have to run it in a loop (as noted now in the blog and seen in the systemd issue). At that point I saw that there was a Fedora tracking bug, someone requested a CVE and there were patches proposed on the systemd issue (which has since been closed/fix merged), so I moved on with life. Next someone posted the blog link to the fedora users list along with a rebuttal from a systemd maintainer: https://medium.com/@davidtstrauss/how-to-throw-a-tantrum-in-one-blog-post, and the discussion went downhill quickly from there. Finally, I saw a slashdot post today with the calm, journalistic title of Multiple Linux Distributions Affected By Crippling Bug In Systemd (which points to the blog post above that started all this). So, everyone is flaming everyone else again about systemd, and I just don't get it. My personal relationship with systemd is well within the range of all the other Open Source projects I use every day. Mostly I am happy with it, sometimes it has bugs and I report them, sometimes the project makes decisions I don't like or agree with, sometimes the project doesn't communicate as well with downstream as I would like (see fedora devel list post about systemd and TasksMax ), sometimes I have to learn (again) how to do what I want to do, sometimes it's slow when I want it to be fast and so on. Would a local denial of service attack in another project have (re)opened such a bunch of flames? There was in fact just the day before the post a remote denial of service in bind (the most popular dns server out there). Did you even hear about it? I just don't get the passionate hatred systemd has. I guess perhaps I never will, and I guess thats ok. I would kindly ask those who do passionately dislike systemd to just move on to somewhere without it and leave the rest of us alone, but I don't expect thats likely to happen. In the mean time if you have some technical problem with systemd, I will be happy to help you isolate it and file a bug or teach you how to do whatever you are trying to do with it, but I'm going to try and stay out of your flamewars.

A while back I added a task to my taskwarrior database: evaluate how things were going at 6 months of use. Today is that day. :) A quick recap: about 6 months ago I switched from my ad-hoc list in a vim session and emails in a mailbox to using task warrior for tracking my various tasks ( http://taskwarrior.org/ ) Some stats: Category Data Pending 17 Waiting 20 Recurring 12 Completed 1094 Deleted 18 Total 1161 Annotations 1059 Unique tags 45 Projects 10 Blocked tasks 0 Blocking tasks 0 Data size 2.0 MiB Undo transactions 3713 Sync backlog transactions 0 Tasks tagged 39.8% Oldest task 2016-03-24-13:45 Newest task 2016-09-25-10:03 Task used for 6mo Task added every 3h Task completed every 4h Task deleted every 10d Average time pending 4d Average desc length 32 characters Overall I have gotten a pretty good amount of use from task. I do find it a bit sad that I have only been completing a task every 4 hours and adding one every 3 hours. At that rate things aren't going to be great after a while. I have been using annotations a lot, which I think is a good thing. Looking back at old tasks I can get a better idea of what I did to solve a task or more context around it (I always try and add links to bugzilla or trac or pagure if there's a ticket or bug involved). I'd say I am happier for using task and will continue using it. It's very nice to be able to see what all is pending and easily add things when people ask you for things and you are otherwise busy. I'd recommend it to anyone looking for a nice way to track tasks.

NetworkManager has pretty handy vpn handling for laptops. You can setup all different kinds, it can prompt you for passphrases, it can set up specific vpns on specific networks, etc. However, if you had more than 1 vpn you wanted to run at a time you had to pick one for NetworkManager to handle and do the other(s) outside NetworkManager. This is happily no longer the case (at least with NetworkManager 1.4.0): It can bring up as many vpns as you like and manage them all. This weekend I took my home openvpn connection (which I had setup as a system wide openvpn service) and moved it into a NetworkManager vpn profile. It works just fine with my work vpn and now NetworkManager can bring it up automatically after it connects to the network. So, if you need two (or more) vpns on your laptop, you can now happily move them all into NetworkManager. Many thanks to the hard working NetworkManager folks. :)

My flight was leaving sunday so that gave me an extra day in Krakow to do some recovery and visiting with folks that hadn't left yet. Pingou and I had breakfast and then headed down to the city center to get some shopping and touristing done. Dennis Gilmore and Peter Robinson joined us. It was much cooler today than it had been, and a light mist/rain was falling. We did some shopping and walked around the castle, then pingou had to head out to his flight. Dennis and Peter and I had lunch in a basement restaurant. It was nice, but we had no polish speakers with us and they didn't have much english, but it worked out fine in the end. The rain started coming down much harder then, so we decided to head back to the hotel. Back to the hotel to catch up on email and blogs. Which reminds me: remember that flock is great for discussing things, but you should always present them to your community that wasn't present for their input before just deciding them. The items we discussed in the infra workshop the other day still need to be discussed on the infra list next week and more input gathered before we decide on anything. Sunday was a day of travel. I had no problems, but 15 hours of flights and standing in queues does wear. The customs at DIA took a while, it seems about 3 international flights landed at the same time, so all the lines were long, but I managed to make it home in the end. Next week: communicating discussions at flock and catching up on everything! A quick shout out to the folks organizing flock: great job! Everything ran very smoothly and professionally. You all rock!