I’m holding a Debian packaging workshop for our trainees at work tomorrow, and have prepared a sample package for a simple PHP web application (just a handful of files) with DB connection (PostgreSQL of course), automatic setup via dbconfig-common, and with support for both Apache 2.2 (wheezy, precise) and Apache 2.4 (jessie/sid), configuration-wise. (It is possible to install this without Apache, just it does not configure the webserver then.) Schema updates on software updates are also tested (there is neither Flyway nor Liquibase – which are the tools we use at work for this, other than Roland Mas’ wonderful scripts for FusionForge – in Debian, but to my delight I discovered that dbconfig-common can also do this).
Comments, suggestions, flames, etc. welcome. I know that this should not be a native package, and will address this tomorrow, but I wanted something that serves as decent example for how to do this easily, Policy conformant and using modern techniques (even those I dislike myself – for the sake of simplicity).
Permission was granted by the business administration to reproduce this all under a BSD-style licence, so, enjoy sharing!
Thanks to Roland Mas, for making FusionForge such a nice project, and Arno Töll for some instant IRC help on the Apache side of this.
(And next week or so, I’ll need this for a Maven thingy. I’ll probably opt out on the DB side, there, though. Never did anything with that, either, not being a Java™ guy. I guess something web to go with tomcat7… anyone got this already?)
Endlich tut mal jemand was gegen die rechte Hetzpartei! – Ein Arbeitskollege fragt, ob man die nicht einfach mit einem langen Heckenschneider abmachen kann… aber sie so lächerlich zu machen hat auch was ☺
Finally, someone is doing something against this Nazi party! A coworker wondered whether it’s legal to cut them off with a long tool, but making them ridiculous like this is also funny ☻
(Explanation: the “Pro NRW” people put their campaign thingies (sorry, I don’t speak English well) up on lamp posts very high, because they are taken down by other citizens immediately otherwise, so there’s now people making fun of them for using long ladders (to put them up there, so the offended citizens need equally long ladders or tools with long arms) in leaning on the saying that lies have long legs ⇒ here: ladders.)
While taking the tram to our favourite Croatian restaurant, I spotted something dedicated to Ada. We’ll never know which one… the language, the famous programmer, or someone else. A “Maibaum” (may pole, one of its many meanings). Click on the picture to get a slightly different one which has the text better legible.
I was out, seeing something that wasn’t there yet when I was at school (the “web” was not ubiquitous, back then), and decided to have a look:
Ugh. Oh well, PocketIE doesn’t provide a “View Source” thingy, so I asked Natureshadow (who got the same result on his Android, and had no “View Source” either apparently, so he used cURL to see it). We saw (here, re-enacted using ftp(1)):
tg@blau:~ $ ftp -Vo - http://www.draitschbrunnen.de/ <!-- pageok --> <!-- managed by puppet --> <html> <pre>pageok</pre> </html>
This is the final straw… after puppet managed to trash a sudoers(5) at work (I warned people to not introduce it) now it breaks websites. ☺
(Of course, tools are useful, but at best to the skill of their users. Merely dumbly copying recipes from “the ’net” without any understanding just makes debugging harder for those of us with skills.)
ObQuestion: Does anyone have ⓐ a transcript (into UTF-8)
and ⓑ a translation for the other half of the OpenBSD
2.8 poster? (I get asked this regularily.)
Update: One person sent me the Kanji and Kana for it in UTF-8 「俺のマシンに手を出すな！」, and they and one more person told me it’s “Hands off my machine!” or “Don’t lay a hand on my machine!”. Now I’m not studying Japanese, but it LGTM in FixedMisc [MirOS], and JMdict from MirPorts says: ore no mashin ni te (w)o dasu na (roughly: my machine; particle; hands; particle; put out; prohibition) ☺ Thanks all, now I know what to tell visitors who wonder about that poster on my wall.
ObTip: I can install a few hundred Debian VMs at work manually before the effort needed to automate d-i would amortise. So I decided not to. Coworkers are shocked. I keep flexibility (can decide to have machines differ), and the boss accepts my explanations. Think before doing automation just for the sake of automation!
I’ve been only sleeping, cooking and geocaching this weekend. Rather productive. Better than being angry at idiots, slowpokes (StartCom and Mozilla in particular), etc.
Food was rather tasty, although I held back and put only ten pieces of garlic into it; gecko2 added some Pul Biber to his…
First of all, good news, MirBSD is not vulnerable to The Heartbleed Bug due to my deliberate choice to stick to an older OpenSSL version. My inquiry (in various places) as to what precisely could leak when a vulnerable client connected to a nōn-vulnerable server has yet to be answered, though we can assume private key material is safe.
Now the bad news: while the CA I use¹ and a CA I don’t use offer free rekeying (in general), a CA I also use occasionally² refuses to do that. The ugly: they will not even revoke the certificates, so any attacker who gained your key, for example when you have been using a certificate of theirs on a Debian system, will be able to use it (e.g. to MITM your visitors traffic) unless you shell over lots of unreasonable money per certificate. (Someone wrote they got the fee waived, but others don’t, nor do I. (There’s also a great Twitter discussion-thingy about this involving Zugschlus, but I won’t link Twitter because they are not accessible to Lynx users like me and other Planet Debian authors.)
① I’ve been using GoDaddy privately for a while, paid for a wildcard certificate for *.mirbsd.org, and later also at work. I’ve stopped using it privately due to current lack of money.
② Occasionally, for nōn-wildcard gratis SSL certificates for HTTP servers. Startcom’s StartSSL certificates are unusable for real SSL as used in SMTP STARTTLS anyway, so usage isn’t much.
Now I’ve got a dilemma here. I’ve created a CA myself, to use with MirBSD infrastructure and things like that – X.509 certificates for my hosts (especially so I can use them for SMTP) and possibly personal friends (whose PGP key I’ve signed with maximum trust after the usual verification) but am using a StartSSL certificate for www.mirbsd.org as my GoDaddy wildcard certificate expires in a week or so (due to the aforementioned monetary issues), and I’d rather not pay for a limited certificate only supporting a single vhost. There is absolutely no issue with that certificate and key (only ever generated and used on MirBSD, only using it in Apache mod_ssl). Then, there’s this soon-to-be tax-exempt non-profit society of public utility I’m working with, whose server runs Debian, and which is affected, but has been using a StartSSL certificate for a while. Neither the society nor I can afford to pay for revocation, and we do not see any possible justification for this especially in the face of CVE-2014-0160. I expect a rekey keeping the current validity end date, and would accept a revocation even if I were unable to get a new certificate, since even were we to get a certificate for the society’s domain from someplace else, an attacker could still MITM us with the previous one from Startcom.
The problem here is: I’d really love to see (all of!) Startcom dropped from the global list of trustworthy CAs, but then I’d not know from where to get a cert for MirBSD; Globalsign is not an option because I will not limit SSL compatibility to a level needed to pass their “quality” test… possibly GoDaddy, ISTR they offer a free year to Open Source projects… no idea about one for the society… but it would solve the problem of not getting the certificates revoked. For everyone.
I am giving Startcom time until Friday after $dayjob (for me); after that, I’ll be kicking them off MirBSD’s CA bundle and will be lobbying for Debian and Mozilla to do the same.
Any other ideas of how to deal with that? I’d probably pay 5 € for a usable certificate accepted by people (including old systems, such as MSIE 5.0 on Win2k and the likes) without questioning… most of the time, I only serve public content anyway and just use SSL to make the NSA’s job more difficult (and even when not I’m not dealing with any payment information, just the occasional login protected area).
By the way, is there any way to access the information that is behind a current-day link to groups.google.com with Lynx or Pine? I can’t help but praise GMane for their NNTP interface.
ObFunfact: just when I was finished writing this wlog entry, I got a new eMail “Special offer just for you.” from GoDaddy. Sadly, no offer for a 5 € SSL certificate, just the usual 20-35% off coupon code.
I would like to publicly apologise for the inconvenience caused by my recent updates to the mediawiki and mediawiki-extensions source packages in Debian wheezy (stable-security).
As for reasons… I’m doing Mediawiki-related work at my dayjob, as part of FusionForge/Evolvis development, and try to upstream as much as I can. Our production environment is a Debian wheezy-based system with a selection of newer packages, including MediaWiki from sid (although I also have a test system running sid, so my uploads to Debian are generally better tested). I haven’t had experience with stable-security uploads before, and made small oversights (and did not run the full series of tests on the “final”, permitted-to-upload, version, only beforehand) which led to the problems. The situation was a bit complicated by the need to update the two packages in lockstep, to fight an RC bug file/symlink conflict, which was hard enough to do in sid already, plus the desire to fix other possibly-RC bugs at the same time. I also got no external review, although I cannot blame anyone since I never asked anyone explicitly, so I accept this as my fault.
The issues with the updates are:
- mediawiki 1.19.5-1+deb7u1 (the previous stable-security update) was not made by me but by Jonathan Wiltshire
- mediawiki 1.19.11+dfsg-0+deb7u1 (made by me) was fine, fixed the bugs it was supposed to, but was delayed after being uploaded to security-master-unembargoed
- mediawiki 1.19.14+dfsg-0+deb7u1 was supposed to be a mostly upstream update, but I decided to add changes to fix issues pointed out by lintian (not trivial ones), and mistakenly forgot to remove two lines that should not have crept in from sid
- mediawiki 1.19.14+dfsg-0+deb7u2 was quickly uploaded to fix this issue but took about half a day to be ACCEPTed
- mediawiki-extensions 3.5~deb7u1 should have be named 2.12 but could not, due to the aforementioned lockstep update requirement and version checks in maintainer scripts; it fixes the issues but does not add other changes from 3.5 in sid… unfortunately, the packaging uses cdbs (which I dislike quite a lot, but as the newcomer in the team I decided to accept it and go on; changing the existing packaging would be quite some effort anyway) and wants debian/control to be regenerated from control.in… which I thought I had done, and normally do…
- mediawiki-extensions 3.6 (in sid) fixes another dir/symlink conflict shown up after 3.5 was made. I’ve requested upload permission for regenerating debian/control and asked whether I am allowed to include this fix as well
My unfamiliarity with some of the packaging concepts used here, combined with this being something I do during $dayjob (which can limit the time I can invest, although I’m doing much more work on Mediawiki in Debian than I thought I could do on the job), can cause some of those oversights. I guess I also should install a vanilla wheezy environment somewhere for testing… I do not normally do stable uploads (jmw did them before), so I was not prepared for that.
And, while here: thanks to the Debian Security Team for putting up with me (also in this week’s FusionForge issue), and thanks to Mediawiki upstream for agreeing to support releases shipped in Debian stable for longer support, so we can easily do stable-security updates.
ObRant: DST (Sommerzeit) sucks!
Just saw this in my INBOX:
B. The default init system for jessie will be a single /etc/rc script
I’d certainly vote that❣
Update 10.02.2014: The unobfuscated version of cable3 is called 8086tiny under the MIT licence. Thanks to the author for doing that (and not just dumping the IOCCC code) and to RT from the mksh(1) IRC channel for finding it on the ’net!
As a workaround to the build problem of mksh R49 with some host shells, you can try removing every sequence of backslash + newline in rlimits.opt and sh_flags.opt, for example with the following sequence:
cd /path/to/mksh for f in *.opt; do tr '\n' '`' <"$f" | \ sed 's/\\`//g' | \ tr '`' '\n' >"$f.out" mv "$f.out" "$f" done
This will apply to every upcoming mksh(1) release until such time as this code has been rewritten in (host) C. Another thing that could be done is to add -r to both IFS= read line occurences in Build.sh, function do_genopt.
Meh. I announced a tree breaker. Would be nice if I actually found enough spare time to hack on it before, I think, end of March (which is roughly when I’m planning to decommission both eurynome and, for monetary reasons (not going to do an OpenBSD here and cry about needing funds, as those who know me know this is a constant), the manitu server).
Took me 62 minutes to write a functioning OSIAM installer in mksh(1) after getting annoyed that the Puppet-lovers are either ill, not able to work on the project I have to finish by Friday, or not yet skilled enough to help. Got the entire thing working (but this week sees way too many overlong days at the workplace), estimate finishing with full success by tomorrow afternoon, with zero puppet but lots of mksh. Maintainable, too.
I’ve produced several pin-on buttons to take with me to FOSDEM for giving away (as long as there are any left):
Hm… jupp needs a button’able logo!