Dev Week -- Server oriented packages -- mathiaz -- Mon, Jan 25


   1 [20:02] <mathiaz> allright - let's keep the ball rolling
   2 [20:02] <mathiaz> kees: thanks for your presentation
   3 [20:03] <mathiaz> Hello everyone!
   4 [20:03] <mathiaz> My name is Mathias Gug and am part of the Ubuntu Server team:
   5 [20:03] <mathiaz>
   6 [20:03] <mathiaz> During the next (and final) hour of today's Ubuntu Developer week I'll talk about Server related packages.
   7 [20:04] <mathiaz> These are packages that usually provide services running in the background as daemon. They should be operating smoothly unattended by the system administrator.
   8 [20:04] <mathiaz> I'll cover different topics relevant to server packages. I'll answer any questio
   9 [20:04] <mathiaz> ns on the topic after I've covered it before moving on to the next one.
  10 [20:05] <mathiaz> let's get started with the first topic:
  11 [20:05] <mathiaz> Log files
  12 [20:06] <mathiaz> The location of log files should be /var/log/package.log or /var/log/package/.
  13 [20:06] <mathiaz> The latter version is more frequent for daemons as log files are essential for these programs and multiple logs files are usually created.
  14 [20:07] <mathiaz> For example the apache2 package stores all its log files in /var/log/apache2/:
  15 [20:07] <mathiaz> The access logs are available in one file while the error log is stored in another one.
  16 [20:08] <mathiaz> The Filesystem Hierarchy Standard is followed by Debian and Ubuntu and has a section about the location about log files:
  17 [20:08] <mathiaz>
  18 [20:08] <mathiaz> Since daemons can generate a lot of information while running rotating the logs are important.
  19 [20:09] <mathiaz> The package maintainer should provide a default log rotation policy during package installation.
  20 [20:09] <mathiaz> Some daemons will take care of rotating their logs automatically. Most of them won't though.
  21 [20:10] <mathiaz> The recommended way is to include a configuration file for logrorate.
  22 [20:10] <mathiaz> Let's have a look at the apache2 default logrotate configuration:
  23 [20:10] <mathiaz>
  24 [20:11] <mathiaz> Note that apache2 is reloaded once log files have been rotated. This is a common operation for daemons as they tend to keep their log files opened and need to be told to reopen their log files once logrotate has rotated them.
  25 [20:12] <mathiaz> The logrotate configuration file should be installed as /etc/logrotate.d/package-name:
  26 [20:12] <mathiaz>
  27 [20:12] <mathiaz> There is a debhelper command that can help automate this: dh_installlogrotate
  28 [20:12] <mathiaz> The logrotate man page has more information about the options for log rotation.
  29 [20:13] <mathiaz> Log directories are usually included in the package themselves.
  30 [20:13] <mathiaz> For example, /var/log/apache2/ is part of the apache2-common package:
  31 === test is now known as Guest65958
  32 [20:13] <mathiaz>
  33 [20:14] <mathiaz> However they often need to be changed by maintainer scripts:
  34 [20:14] <mathiaz> In the postinst, ownership and permissions are updated since daemons usually run as a non-root user:
  35 [20:14] <mathiaz>
  36 [20:14] <mathiaz> Log files should also be deleted with the package is purged:
  37 [20:15] <mathiaz>
  38 [20:15] <mathiaz> More information about log files can be found in the relevant section of the Debian policy:
  39 [20:15] <mathiaz>
  40 [20:15] <mathiaz> Any questions related to log files?
  41 [20:16] <cjohnston> < toabctl_> mathiaz, QUESTION: but the apache2 package does not use the dh_installlogrotate command, right?
  42 [20:16] <mathiaz> toabctl_: yes - that is correct
  43 [20:16] <cjohnston> < n3rd> QUESTION: Is there a mechanism to replicate server configurations from one machine to another, helps in avoiding reinstalling and setting up all the parameters, for example a machine had
  44 [20:16] <mathiaz> toabctl_: if it would, it would be done in the debian/rules file
  45 [20:16] <cjohnston>               apache configured with bug tracking system, SCM etc, the same needs to be setup in another machine so it would be easy if we could just replicate the same.
  46 [20:16] <cjohnston> sorry...
  47 [20:17] <mathiaz> n3rd: this is a more generic question - related to configuration management system
  48 [20:17] <mathiaz> n3rd: I'd look into things like puppet, chef or cfengine
  49 [20:17] <mathiaz> cjohnston: next
  50 [20:17] <cjohnston> < toabctl_> QUESTION: does debhelper provide more function to take care for logfile handling? for example package purge..
  51 [20:18] <mathiaz> toabctl_: I don't think so
  52 [20:18] <mathiaz> anything other questions related to log files before we move on?
  53 [20:19] <cjohnston> That looks like it. :-)
  54 [20:19] <mathiaz> nope - let's move on to the next topic then:
  55 [20:19] <mathiaz> Configuration files
  56 [20:19] <mathiaz> Dealing with configuration files should be guided by the following principles:
  57 [20:19] <mathiaz> 1. Keep the user modification during upgrades
  58 [20:20] <mathiaz> 2. Have a default working configuration after package install
  59 [20:20] <mathiaz> Per the Debian Policy:
  60 [20:20] <mathiaz> A configuration file """affects the operation of a program, or provides site- or host-specific information, or otherwise customizes the behavior of a program. Typically, configuration files are intended to be modified by the system administrator (if needed or desired) to conform to local policy or to provide more useful site-specific behavior."""
  61 [20:20] <mathiaz>
  62 [20:21] <mathiaz> All configuration files must reside in /etc/.
  63 [20:21] <mathiaz> Configuration files must only be removed on package *purge*, not on package *removal*.
  64 [20:21] <mathiaz> Packages should not modify configuration files belonging to other packages.
  65 [20:22] <mathiaz> In order to have a working configuration file by default the package can either ship a default configuration file or generate one during installation by asking questions to the user.
  66 [20:22] <mathiaz> The first option should be used if possible. Shipping a default configuration file as part of the package itself under /etc/ is the easiest way.
  67 [20:22] <mathiaz> Files will be considered as conffile by dpkg which will handle them for you during package upgrades.
  68 [20:23] <mathiaz> This is appropriate only if it is possible to distribute a default version that will work for most installations, although some system administrators may choose to modify it.
  69 [20:23] <mathiaz> This implies that the default version will be part of the package distribution, and must not be modified by the maintainer scripts during installation (or at any other time).
  70 [20:23] <mathiaz> For example /etc/apache2/apache2.conf is a conffile:
  71 [20:24] <mathiaz>
  72 [20:24] <mathiaz> It's installed during the package build via a rule:
  73 [20:24] <mathiaz>
  74 [20:24] <mathiaz> The other solution to provide a default working configuration file is to generate a valid one during package installation.
  75 [20:25] <mathiaz> Various maintainer scripts are used to ask questions to the end user (optional) and then create a configuration file.
  76 [20:25] <mathiaz> They will also handle all configuration changes during package upgrade.
  77 [20:25] <mathiaz> One option is to generate the configuration file directly in the postinst script as done by the openssh-server package:
  78 [20:25] <mathiaz>
  79 [20:26] <mathiaz> Quite often this is combined with debconf questions.
  80 [20:26] <mathiaz> The user is asked for information by the package .config script. The postinst script generates the configuration file according to the user answers.
  81 [20:27] <mathiaz> Another great practice for configuration is the use of /etc/package.d/ include directories.
  82 [20:27] <mathiaz> If the program supports configuration file inclusion I strongly recommend to ship a default file that include a /etc/package.d/ directory.
  83 [20:27] <mathiaz> That often helps other packages to integrate with your program by dropping their own configuration file in the /etc/package.d/ directory.
  84 [20:27] <mathiaz> For example apache2 includes a configuration directory in its default configuration file:
  85 [20:27] <mathiaz>
  86 [20:28] <mathiaz> The apache2 package actually provides multiple .d directories:
  87 [20:28] <mathiaz> A conf.d for generic options:
  88 [20:28] <mathiaz>
  89 [20:28] <mathiaz> A modules.d (called mods-available) to enable specific modules:
  90 [20:28] <mathiaz>
  91 [20:29] <mathiaz> Thanks to this directory packages providing a specific apache2 modules can just ship a configuration file in /etc/apache2/mods-available/. There is no need to edit a configuration file.
  92 [20:29] <mathiaz> A sites.d (called sites-available) to manage virtual hosts:
  93 [20:29] <mathiaz>
  94 [20:29] <mathiaz> This is more targeted at sysadmin rather than package maintainers.
  95 [20:30] <mathiaz> The apache2 package is a great example to look at how a package can provide the infrastructure to help other packages integrated with it.
  96 [20:30] <mathiaz> More detailed about configuration files handling can be found in the Debian policy:
  97 [20:30] <mathiaz>
  98 [20:30] <mathiaz> For more information about Debconf:
  99 [20:30] <mathiaz>
 100 [20:30] <mathiaz> Any questions related to configuration files?
 101 [20:31] <mathiaz> QUESTION: how to handle a file which is needed in the directory /usr/share/pyshared/testprogram/ ? just add a symlink from /usr/share/pyshared/testprogram to /etc/testprogram/ ?
 102 [20:32] <mathiaz> toabctl_: yes - that usually how things should be done
 103 [20:32] <mathiaz> toabctl_: all configuration files should be in /etc/
 104 [20:32] <cjohnston> < n3rd> Q: how can i avoid trailing slashes in conf files
 105 [20:33] <mathiaz> toabctl_: if programs are not able to handle, that it's advised to use symlink from /etc/ to the expected location
 106 [20:33] <mathiaz> n3rd: I'm not sure I understand your question
 107 [20:33] <cjohnston> < n3rd> Q: why some refer to httpd.conf and some to apache.conf, how exactly they work?
 108 [20:34] <mathiaz> n3rd: this is specific to how apache2 is working
 109 [20:34] <mathiaz> n3rd: IIRC httpd.conf is around for historical reasons
 110 [20:34] <mathiaz> n3rd: apache.conf should include httpd.conf
 111 [20:35] <cjohnston> < n3rd> Question : instead of localhost/test, how can i configure apache2 to point localhost:port to test dir in /var/www
 112 [20:35] <mathiaz> n3rd: that's a support question for apache2 - I won't address it here
 113 [20:35] <mathiaz> n3rd: I'd suggest to ask the question in #ubuntu-server
 114 [20:36] <mathiaz> I think that's all for this topic - let'sm ove on
 115 [20:36] <mathiaz> next topic: Upstart job
 116 [20:36] <mathiaz> The init script subsystem in Ubuntu has seen a lot of activity in the past releases as we're moving more and more to upstart jobs.
 117 [20:36] <mathiaz> I'll give an overview on some features from upstart that are very helpful in managing daemons.
 118 [20:37] <mathiaz> Upstart is able to supervise services: if a process dies Upstart can be configured to restart it.
 119 [20:37] <mathiaz> For example, the openssh-server upstart job:
 120 [20:37] <mathiaz>
 121 [20:37] <mathiaz> Using the respawn keywork instructs upstart to restart the sshd process if it disappears:
 122 [20:38] <mathiaz> Line11
 123 [20:38] <mathiaz> Upstart also supports forking daemons and will supervise them correctly:
 124 [20:38] <mathiaz> Line10
 125 [20:38] <mathiaz> Some daemons could also be run in the foreground by upstart:
 126 [20:38] <mathiaz>
 127 [20:38] <mathiaz> Another strength of Upstart is its dependency system. If a service is restarted other daemons may need to be restarted as well.
 128 [20:39] <mathiaz> For example if the portmap service is restarted, gssd and statd will automatically be restarted by upstart as well:
 129 [20:39] <mathiaz>
 130 [20:39] <mathiaz> Upstart has built-in support for oom handling:
 131 [20:39] <mathiaz>
 132 [20:39] <mathiaz> Other features include nicing  and setting limits. See init(5) manpage for more information.
 133 [20:40] <mathiaz> Traditionally daemon init scripts would source /etc/default/servicename. The default file provides an easy way to customize major options for the system administrator.
 134 [20:40] <mathiaz> In Upstart it's suggested to modify directly the upstart job instead.
 135 [20:40] <mathiaz> Upstart jobs should be defined in debian/package.upstart. They will be automatically handled by the relevant debhelper scripts (such dh_installinit).
 136 [20:41] <mathiaz> More information can be found in the init(5) manpage  and the Debian policy.
 137 [20:41] <mathiaz> And don't forget the upstart website at:
 138 [20:41] <mathiaz>
 139 [20:42] <mathiaz> Any question related to upstart?
 140 [20:43] <cjohnston> < bullgard> QUESTION: What do you mean by "service" here?
 141 [20:43] <mathiaz> bullgard: I think this has already been well answered in -chat
 142 [20:44] <cjohnston> That's all I see
 143 [20:44] <mathiaz> rmunn_: thanks
 144 [20:44] <cjohnston> < zul> QUESTION: when would you use fork and when would you use daemon?
 145 [20:44] <mathiaz> zul: not sure
 146 [20:45] <cjohnston> < rmunn> QUESTION re upstart: How difficult is a typical init-to-upstart conversion? E.g., if I have a package using init scripts, is it usually worth the effort of rewriting its init scripts to use
 147 [20:45] <cjohnston>                upstart instead? How much is gained to offset the cost of the rewrite?
 148 [20:45] <mathiaz> rmunn_: it depends on complex the init script is
 149 [20:46] <mathiaz> rmunn_: usually it's worth the effort - as there is bunch of new features that upstart handles automatically for you
 150 [20:46] <mathiaz> rmunn_: and if you do a lot of funky stuff in the init script (like modify configuration files), you can just use the same code in the pre/post-script stanzy in the upstart job
 151 [20:46] <mathiaz> rmunn_: so quite often you can just copy and paste the code
 152 [20:47] <mathiaz> all right - let's move on
 153 [20:47] <mathiaz> Next topic: UFW profile
 154 [20:47] <mathiaz> The security team wrote a simple host-based firewall tool named UFW:
 155 [20:47] <mathiaz>
 156 [20:47] <mathiaz> Package integration is now available by dropping a file in /etc/ufw/applications.d/ to tell ufw how to configure firewalling rules for the services.
 157 [20:47] <mathiaz> For example here is openssh-server ufw profile:
 158 [20:47] <mathiaz>
 159 [20:48] <mathiaz> And how to install it during the package build:
 160 [20:48] <mathiaz>
 161 [20:48] <mathiaz> For more information see the ufw wiki page at:
 162 [20:48] <mathiaz>
 163 [20:49] <mathiaz> any question related to UFW?
 164 [20:50] <cjohnston> None seen
 165 [20:50] <mathiaz> allright then - let's move on
 166 [20:50] <mathiaz> Next topic: AppArmor profile
 167 [20:50] <mathiaz> Another tool that the security team is maintaining and the proves to be useful for services is AppArmor.
 168 [20:50] <mathiaz> It can be seen as an alternative to chroots for daemons.
 169 [20:51] <mathiaz> For example here is the ntp apparmor profile:
 170 [20:51] <mathiaz>
 171 [20:51] <mathiaz> It should be installed in /etc/apparmor.d/
 172 [20:51] <mathiaz>
 173 [20:51] <mathiaz> Some care needs to be taken during package upgrade especially when a new profile is introduced as we don't want to break existing systems.
 174 [20:52] <mathiaz> More information about migrating a profile can be found on the wiki page:
 175 [20:52] <mathiaz>
 176 [20:52] <mathiaz> And you can find more info on the AppArmor wiki page:
 177 [20:53] <mathiaz>
 178 [20:53] <mathiaz> any question related to AppArmor profiles?
 179 [20:53] <cjohnston> None seen
 180 [20:54] <mathiaz> ok - let's move on
 181 [20:54] <mathiaz> next topic: system users
 182 [20:54] <mathiaz> One of the Ubuntu goal is to try to run as many daemons as possible as non-root users.
 183 [20:54] <mathiaz> That brings the need to create system users. The best practice is to not delete users on package purge. Otherwise the uid could be reallocated, potentially giving access to files from the previous package to the new program.
 184 [20:55] <mathiaz> For example the openssh-server postinst creates the ssshd user if the user doesn't already exists:
 185 [20:55] <mathiaz>
 186 [20:55] <mathiaz> If the daemon requires to be run as root try to write an AppArmor profile for it.
 187 [20:56] <mathiaz> More information about system users can be found in the Debian policy:
 188 [20:56] <mathiaz>
 189 [20:56] <mathiaz> Any question related to system users?
 190 [20:57] <mathiaz> nope - let's move on then
 191 [20:57] <mathiaz> Next topic: Cron jobs
 192 [20:57] <mathiaz> Cron jobs should installed in /etc/cron.d/ or any of the regular cron directory (ex: /etc/cron.daily/).
 193 [20:58] <mathiaz> There is a debhelper script available for packager: dh_installcron.
 194 [20:58] <mathiaz> The Debian policy has more information:
 195 [20:58] <mathiaz>
 196 [20:58] <mathiaz> Any questions related to cron jobs?
 197 [20:59] <cjohnston> None seen...
 198 [20:59] <mathiaz> allrigh then
 199 [20:59] <mathiaz> that's all for now then
 200 [20:59] <mathiaz> you can find more information in the following guides:
 201 [20:59] <mathiaz>  * Debian policy: - - debian-policy package
 202 [20:59] <mathiaz>  * Debian Developer's Reference: -
 203 [20:59] <mathiaz>  * Debian New Maintainers' Guide: -
 204 [20:59] <mathiaz>  * Ubuntu Policy: - ubuntu-policy package
 205 [21:00] <mathiaz>  * Ubuntu Package Guide: -
 206 [21:00] <mathiaz>  * Mailing lists and IRC channels: - ubuntu-devel@, ubuntu-server@ - #ubuntu-devel, #ubuntu-server
 207 [21:00] <mathiaz>  * Ubuntu wiki: -
 208 [21:00] <mathiaz> And one last page that I often use when I have my packager hat:
 209 [21:00] <mathiaz>
 210 [21:00] <mathiaz> this one outlines the sequence in which maintainer scripts are called
 211 [21:01] <mathiaz> and with that the first day of the Ubuntu Developer Week is ending
 212 [21:01] <mathiaz> come back for more tomorrow, same place at 16:00 UTC
 213 [21:02] <mathiaz> you'll learn about java libraries, ubuntu one support, automated server testing and other things
 214 [21:02] <mathiaz>
 215 [21:02] <mathiaz> thanks all and bye!

MeetingLogs/devweek1001/ServerPkgs (last edited 2010-11-01 10:46:11 by klabs)