Merge lp:~widelands-dev/widelands-website/add_ops into lp:widelands-website

Proposed by SirVer
Status: Merged
Merged at revision: 419
Proposed branch: lp:~widelands-dev/widelands-website/add_ops
Merge into: lp:widelands-website
Diff against target: 23 lines (+18/-0)
1 file modified
_ops/apt_update.sh (+18/-0)
To merge this branch: bzr merge lp:~widelands-dev/widelands-website/add_ops
Reviewer Review Type Date Requested Status
kaputtnik (community) Approve
Review via email: mp+302269@code.launchpad.net

Description of the change

Adds the script I regularly run on the server to update everything.

To post a comment you must log in.
Revision history for this message
kaputtnik (franku) wrote :

I am unsure if this should be a part of the website, because it affects the whole server system. And this is Debian/Ubuntu specific.

If one forgot to run this script and use the regular commands the errors will be shown again. So maybe a global alias would do the trick? Something like:

alias update_server='sudo /path/to/apt_update.sh'

Maybe it is possible to overwrite the 'apt-get update' command with an alias? So if one writes 'sudo apt-get update' in the console the script is executed (maybe prints an explanation whats going on). But i don't know if this is possible (didn't found an example)

Why not create a cron job for this?

Maintenance site:
janus has changed the code in /etc/nginx/sites-available/wl.widelands.org to provide a maintenance site, but the provided solution (comment/uncomment pieces of code) isn't applicable for doing this in a script. I have searched around for this and found mostly solutions were nginx provide a maintenance site when a specific file is found. This seems to me a better solution (just move a file/create a symlink) to a specific place where nginx find it), but i am afraid to play with the nginx configuration (have also work enough with other stuff ;) ).

The maintenance site is stored in /var/www/www.widelands.org/htdocs/index.html

The _ops directory is good though.

Revision history for this message
GunChleoc (gunchleoc) wrote :

I would not worry too much about the script only being applicable for the server - we are doing this development for our server anyway. We are already doing something similar with the translations update shell script, which used to be a private script of SirVer's as well.

Revision history for this message
SirVer (sirver) wrote :

kaputtnik, I know where you are coming from - I also preferred having source and tools separate before - it just feels cleaner. I came to the conclusion though that it is easier and preferable to keep the ops tools with the source code. It makes the audit trail easier (i.e. which scripts get run and when) and the scripts are consistently used and developed - independent of who is working on the server. It is a sort of runnable documentation.

I think the alias is hard to maintain and enforce - I guess we just have to remember that we have an ops script for this.

> Why not create a cron job for this?

apt-get update's can fail and/or query for decisions. An admin needs to make the calls there (which usually are: keep the config files that are in place and/or reload all services). I prefer doing this manually - I do it every 30 days.

> Re: Maintenance site

I wrote semi complex upstart scripts for the website and alpha (which are run through sudo start wlwebsite). We could change these to start the maintenance site instead. I think these upstart scripts should also be checked in and the ones in /etc/init/* should be symlinks the ones in the repository. This is also ops, of course.

Revision history for this message
kaputtnik (franku) wrote :

I think this looks good but i am still unsure...

Where is the border to decide which things get in the ops directory of the website?

But i will not start an endless discussion :-)

review: Approve
Revision history for this message
kaputtnik (franku) wrote :

One question:

> apt-get update's can fail and/or query for decisions. An admin needs to make the calls there (which usually are: keep the config files that are in place and/or reload all services). I prefer doing this manually - I do it every 30 days.

In the script there is the '-y' option for the commands, which means all questions are autoanswered with 'yes'. As i understand this would mean you couldn't do the things manually when running this script.

418. By SirVer

Remove -y on the apt-get update line.

Revision history for this message
SirVer (sirver) wrote :

> Where is the border to decide which things get in the ops directory of the website?

one possible way to decide: if you wrote a set of 3 or more commandlines 3 or more times already in the same or similar ordering and you expect it to write it again if you think about it for a moment, make it a script and check it into _ops. Should you have been wrong about it in a few months, we delete it again - no biggy.

> In the script there is the '-y' option for the commands, which means all questions are autoanswered with 'yes'. As i understand this would mean you couldn't do the things manually when running this script.

Good call. I removed the -y again, since I think it is valuable to leave these decisions to the admin running the script.

Gonna merge now.

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
1=== added directory '_ops'
2=== added file '_ops/apt_update.sh'
3--- _ops/apt_update.sh 1970-01-01 00:00:00 +0000
4+++ _ops/apt_update.sh 2016-08-10 10:31:54 +0000
5@@ -0,0 +1,18 @@
6+#!/bin/sh
7+# Updates all packages on the server, but stops the widelands website before
8+# doing so, in case mysql gets updated - it always results in really ugly
9+# errors for users otherwise. Ideally, this script would switch the website to
10+# a "In Maintenance" banner.
11+#
12+# This script requires root access.
13+
14+set -ex
15+
16+apt-get update
17+stop wlwebsite
18+
19+apt-get dist-upgrade
20+
21+start wlwebsite
22+
23+apt-get autoremove -y

Subscribers

People subscribed via source and target branches