OMG. There is a bug, damn. Can’t continue today.
-> Next day
Oh, the bug is gone, great! *continuing* 🙂
OMG. There is a bug, damn. Can’t continue today.
That was Wacken: Mud.
To say it with the words of the organisation and police: It was the muddiest, but also the smoothest Wacken since it started 26 years ago. Almost no criminal actions and an overall nice chillout feeling.
Here a short overview:
Tuesday 2000 – Standing in the traffic jam just before the Wacken area, having some stress with some stupid security guards, because they didn’t even know what’s going on.
Tuesday ~2300 – We’re standing on the campground setting up our camping trailer and Martin’s tent.
Wednesday – Rain, 2 minutes dry from above, rain, 20 minutes dry, rain. Did I mention rain? The way to the festival infield tent (Headbangers Stage) for Europe was quite arduous, but nothing against the day after, because of the steady heavy rain during the night. (~100l/m², some said…)
Thursday – Rain was almost gone, finally. But all campground roads were still muddy as hell. So we did a chillout day to recover from the rainy beginning, without much walking around on the infield, except for Savatage and some Eric Fish ‘n’ Friends on the Wackinger Stage.
Friday – Cloudy with some sunshine. Excellent weather from above, drying out the mud at our place, campground V. The roads to the infield were still muddy knee-deep. The infield was also a mud wasteland. But nothing could keep us away from watching Annihilator, In Flames, Running Wild/Within Temptation and some smaller bands on the Wackinger Stage.
Saturday – Last day, finally sunny all day with some single and small clouds. Mud at our camping area went from still wet in the morning to dust in the evening. This great day ended with Sabaton, Judas Priest and a bit of Santiano, fighting our way back in the end through the last mud puddles, being very tired.
Sunday – After a comfortable breakfast we started to pack our things into the camping trailer and started our journey back to our relatives near Elmshorn.
Now we’ll have some vacation from the Wacken-vacation in the north before we travel the 15 hours with the camping trailer back home. 🙂
Some photos may follow, when I get the good ones from our friends. 🙂
… at this WordPress instance.
Quite funny watching the visit statistic going up only for “/wp-login.php”.
Had also some fun watching the silly tries to find the correct password for users like “admin”, “administrator”,”< domain.tld>” or just “< domain>” which all do not exist.
But in the end I decided to stop that statistic spamming with a htpasswd authentication for just wp-login.php, so my stats aren’t filled up with failed loginattempts instead the attacker has to guess the user and the 20 character password of the htpasswd auth first.
Have fun! 😛
… and it’s still often a problem for some.
Living in Austria and having a fixed network connection through the provider A1 can have disadvantages. For example the connection has a maximum of 2.9Mbit/s, because of long lines. But the price is the same as like a 8Mbit/s connection, which is, errm… , unfair.
I can live with the slow connection, when it is stable, which it luckily is.
Then there’s the A1modem, this little white plastic case with a black front. The Wifi of this box is the utterest crap you can find, but that’s not the only thing I encountered: This box has other problems with the packet delivery. I can’t really tell, what’s the exact problem, the only thing I can tell for sure is the fact, that I had problems connecting to several servers. For example I could not connect to the steam network, only after almost 20 tries a connection could be made. An other example is my own server at netcup.de, interestingly my standard ssh connection was not a problem, but since I’ve installed docker with gitlab and had to open a second ssh port only for gitlab, I could not connect to it. I thought there were problems with the open ports on my server, but everything looked more than correct, then I just had the idea to try it with a script, and there it was: in 50 tries I got a connection with ssh on the specific port TWICE! Soo, the problem had to be somewhere else. So I came to the A1modem, after restarting and checking the configuration of every router I had in between and I had the force to command over. After a restart of the A1modem everything runs fine again. Funny, isn’t it?
Here some REALLY funny bits of that problem, traceroutes.
Here the traceroute before the restart of the modem:
traceroute to gitlab.mmo.to (18.104.22.168), 30 hops max, 60 byte packets 1 router.asus.com (10.10.10.254) 0.245 ms 0.333 ms 0.418 ms 2 a1modem.home (10.0.0.138) 1.712 ms 1.738 ms 1.759 ms 3 iridium.mmo.to (22.214.171.124) 1.776 ms 1.939 ms 1.959 ms
And the traceroute after:
traceroute to gitlab.mmo.to (126.96.36.199), 30 hops max, 60 byte packets 1 router.asus.com (10.10.10.254) 0.285 ms 0.510 ms 0.582 ms 2 a1modem.home (10.0.0.138) 1.661 ms 1.656 ms 1.668 ms 3 178-189-143-254.adsl.highway.telekom.at (188.8.131.52) 8.516 ms 9.113 ms 10.233 ms 4 184.108.40.206 (220.127.116.11) 18.357 ms 18.356 ms 18.901 ms 5 18.104.22.168 (22.214.171.124) 21.620 ms 126.96.36.199 (188.8.131.52) 22.680 ms IIX11-AUX11.highway.telekom.at (184.108.40.206) 24.036 ms 6 xe-3-1-0-0.vie10.core-backbone.com (220.127.116.11) 27.388 ms 25.470 ms 14.945 ms 7 ae7-2055.nbg30.core-backbone.com (18.104.22.168) 24.701 ms 26.723 ms 27.989 ms 8 corebackbone.netcup.net (22.214.171.124) 34.185 ms 19.505 ms 21.602 ms 9 iridium.mmo.to (126.96.36.199) 23.647 ms 21.292 ms 22.401 ms
So, what the fuq went wrong here?!
Since I’ve invested some time to get to know docker, updating gitlab is just like starting a new container from a different image.
Thanks to https://github.com/sameersbn, who makes this possible with his docker image for gitlab. 🙂
But it gets smoother.
Still no ‘just call the update command’ but at least better than before. This time a dependency created the most headache: ruby. But creating the package again after upgrade of the whole system from the AUR solved that issue. There are still some warnings and exceptions here and there, but the application is running again.
The upgrade of postgreSQL from 9.3 to 9.4 in the archlinux repository still caught me red-handed and prevented some services from starting. The upgrade instructions are straight forward and the problem was solved in less than 3 minutes.
Server completely up to date and running again is quite a satisfying experience. 🙂
My next concerns are now some more sophisticated backup routines…
Again are GitLab updates quite exhausting. Better to say, not GitLab itself, but the repository updates of Arch Linux in combination with GitLab.
ruby got a new release 2.2 and my GitLab instance is still running on 2.1. A downgrade of ruby prevented my instance from collapsing, but as usual upgrading GitLab is quite painful, because the aur package had never quite completed all tasks correctly as you would expect. And the downgrade messed up other packages relying on ruby, so I’m in the need of getting this fixed. 😐
Maybe I should just announce a GitLab upgrade day every two months on a weekend? Well, won’t do that today for sure, too much can-go-wrongs for a chilly sunday evening. Maybe next weekend. 🙂
Got 6x D-Cell 5000mAh rechargeable battery. [check]
Got LED replacement with 220Lumen. [check]Tested flashlight with dog in complete darkness with fog. [check]
Got flood light. [check!]
Surprise! I’ve got a job offer on stackoverflow.careers.
I got a invitation for that career website quite a long time ago when that thing was still beta and I thought european companies are more addicted to monster, linked.in and xing when it comes to recruitment needs.
Maybe that offer is a hint that this fresh career platform is gaining ground against the big players. The invite only fashion of so.careers may be a bit of a show stopper for popularity, on the other hand they try to gain the elite hackers through this approach.
The stackexchange websites are the quasi standard for FAQs, finally nice to see that platform grow on the careers sector too.