I, Andreas Hasenack, apply for Ubuntu Core Developer

Who I am

I graduated in Electrical Engineering. Worked for a few years in a company in the aerospace industry, but in the civilian area, in a project about installing "black boxes" in trucks and buses to monitor several driving and engine parameters. I then came in contact with a customer who had a nice "intranet" (that's what it was called back then), with internal web sites and a big database backend (oracle). We had to do some development for them, but didn't have access to Oracle, and someone told me that I should try this thing called "linux", "postgresql" and "apache". I did, then installed it at home, and never looked back.

In 1998 I took a post-grad specialization course in the University (a degree higher than graduation, but below masters) in computer networks and went to work for Conectiva, the Brazilian Linux distribution, later renamed to Mandriva, where I stayed until 2008 doing lots of packaging work (RPM) and consulting for enterprise customers in the server area. My main area of expertise was email, authentication (kerberos, pam) and LDAP, and I also spent about half the time working in Conectiva's security team and doing security updates for the distro.

My Ubuntu story

Tell us how and when you got involved, what you liked working on and what you could probably do better.

My involvement

In 2008 I applied for a job in the Landscape team (https://landscape.canonical.com), and got hired as a QA engineer. I had never done any Debian packaging before, just had some ideas about how it worked, had grabbed a few packages here and there to inspect them, looked at patches, etc. apt-get wasn't a stranger, since Conectiva developed apt-rpm back in the day, and the concept of dependency resolution is the same everywhere.

Landscape has a client component, and that means a Debian package that gets installed on machines. It obviously needs to be QA'ed. So that's how I got exposed to Debian packaging "for real" that time.

In April 2017 I started working in the Ubuntu Server Team. That got me back in touch with my "Linux roots" (no pun intended) and immediately I started looking into my old friends kerberos, ldap, samba, etc and searching for bugs to fix. It is in the Ubuntu Server Team that I got introduced to the Debian Merge process, and how this team is looking into improving that process via the Git Ubuntu tooling.

Examples of my work / Things I'm proud of

DEP8 tests I added

• samba (#1696823:

  • samba-extra-dep8-1696823

  • upstreamed to debian: https://salsa.debian.org/andreas-guest/samba/tree/more-dep8-tests

• autofs: https://code.launchpad.net/~ahasenack/ubuntu/+source/autofs/+git/autofs/+ref/cosmic-autofs-dep8-1677751

• krb5 (debian first): https://salsa.debian.org/debian/krb5/merge_requests/2

FTBFS fixes I uploaded

• ocfs2-tools: https://code.launchpad.net/~ahasenack/ubuntu/+source/ocfs2-tools/+git/ocfs2-tools/+ref/bionic-ftbfs

• squid3 (during gcc7 migration): https://bugs.launchpad.net/ubuntu/+source/squid3/+bug/1712668

=== Cooperation with debian and/or upstream===

• autofs: deb bug, dep8 tests, autofs mailing list about patch, investigation about why the lookup-ldap patch was still necessary (link to ubuntu-devel@ post)
• samba:

  • dep8 tests: https://salsa.debian.org/samba-team/samba/merge_requests/1

  • https://salsa.debian.org/samba-team/samba/merge_requests/7: Drop deprecated syslog options from default smb.conf

  • https://salsa.debian.org/samba-team/samba/merge_requests/8: logrotate: only try to reload the services if they are running

• sssd:
  • tests that failed with -Wl,-Bsymbolic-functions enabled (default in ubuntu):

    • https://github.com/SSSD/sssd/pull/632

    • mailing list thread: https://github.com/SSSD/sssd/pull/632

  • https://salsa.debian.org/sssd-team/sssd/merge_requests/1: Create the secrets directory used by sssd-secrets

• squid4 dep8 fixes pushed to debian:

  • https://salsa.debian.org/squid-team/squid/merge_requests/4

  • https://salsa.debian.org/squid-team/squid/merge_requests/5

• bind9:

  • https://salsa.debian.org/dns-team/bind/merge_requests/1 I opened it against bind, but it should have been bind9. Debian merged the fix into the right repository.

• exim4:

  • https://salsa.debian.org/exim-team/exim4/merge_requests/2: Add distro banner (our only delta with Debian). Unfortunately rejected, but we tried.

• dovecot:

  • https://salsa.debian.org/debian/dovecot/merge_requests/1: More DEP8 tests for Dovecot

• autofs:

  • https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901554: please add dep8 tests (there is no salsa repository yet for autofs)

Misc

• libvirt apparmor bug: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1707400. Apparmor was being called in post without dh_apparmor and how that missed the cached profiles

• MIR: http-parser, for sssd: https://bugs.launchpad.net/ubuntu/+source/http-parser/+bug/1638957

• bug-pattern contribution for a samba bug: https://code.launchpad.net/~ahasenack/apport/samba-security-share-bugpattern

• NEW packages:
  • ndctl

    • https://code.launchpad.net/~ahasenack/ubuntu/+source/ndctl/+git/ndctl

    • all history showing how the lintian warnings/errors were addressed: https://code.launchpad.net/~ahasenack/ubuntu/+source/ndctl/+git/ndctl/+ref/master

  • pmdk

    • https://code.launchpad.net/~ahasenack/ubuntu/+source/pmdk/+git/pmdk

    • all history showing how the lintian warnings/errors were addressed: https://code.launchpad.net/~ahasenack/ubuntu/+source/pmdk/+git/pmdk/+ref/master

  • bug showing dialog with upstream about pmdk and ndctl: https://bugs.launchpad.net/bugs/1752378

• qa-regression-testing:
  • Apache update changed behavior which broke one regression testing test. Made an MP to fix that:

    • https://code.launchpad.net/~ahasenack/qa-regression-testing/+git/qa-regression-testing/+ref/apache-2.4.33-wont-start-ssl-compression

• backport that became an sru to bring a new zstd version back into stable releases. *Lots* of testing involved. This included creating a transitional package in bionic.

  • https://code.launchpad.net/~ahasenack/ubuntu/+source/libzstd/+git/libzstd

  • https://bugs.launchpad.net/ubuntu/+source/libzstd/+bug/1717040

• SRU DEP8 investigation and fixes:

  • apache2 sru with failed dep8 tests in xenial, artful, bionic: https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1766186

  • See comments https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1766186/comments/18 (artful) and https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1766186/comments/20 (xenial)

  • new bug filed for libapache2-mod-perl2 dep8 fixes in xenial: https://bugs.launchpad.net/ubuntu/+source/libapache2-mod-perl2/+bug/1779400

• britney hints MP: https://code.launchpad.net/~ahasenack/britney/ocfs2-tools-hints-1.8.5-5ubuntu1/+merge/351928

• Mini migration for bind9

  • https://launchpad.net/ubuntu/+source/bind9/1:9.11.4+dfsg-3ubuntu1

bind-dyndb-ldap 11.1-3ubuntu1build1~ppa1 (Newer version available)  Andreas Hasenack (2018-07-31)
bind9   1:9.11.4+dfsg-3ubuntu1~ppa2 (Newer version available)   Andreas Hasenack (2018-07-30)
debian-installer    20101020ubuntu548~ppa1 (Newer version available)    Andreas Hasenack (2018-08-01)
isc-dhcp    4.3.5-3ubuntu8build1~ppa1 (Newer version available) Andreas Hasenack (2018-07-31)
- missed bind-dyndb-ldap in the rdepends output, thinking it was part of bind9, but it's a separate source. Got it sponsored.
- thought isc-dhcp wasn't needed, because the old bind package with the old soname would still be around. Even tested that scenario:
  jul 31 15:44:10 <ahasenack>     and upgrading just bind, leaving isc-dhcp without a rebuild, also works: https://pastebin.ubuntu.com/p/zkw8nzryYV/
  Got it sponsored.
- found out about debian-installer's rdepends via update_output.txt, and asked for a rebuild/sponsorship:
  ago 01 14:37:54 <ahasenack>     hi, my bind9 upload, which bumped the soname, also needs a debian-installer rebuild (ppa at https://launchpad.net/~ahasenack/+archive/ubuntu/bind-merge-9.11.4/+packages). Would someone sponsor this for me? https://pastebin.ubuntu.com/p/HPVtSzkPK7/
  Got it sponsored.

TL;DR rebuilds:
https://launchpad.net/ubuntu/+source/bind-dyndb-ldap/11.1-3ubuntu2
https://launchpad.net/ubuntu/+source/isc-dhcp/4.3.5-3ubuntu9
https://launchpad.net/ubuntu/+source/debian-installer/20101020ubuntu548

Areas of work

Let us know what you worked on, with which development teams / developers with whom you cooperated and how it worked out.

• Package maintenance for Conectiva/Mandriva: before Canonical, I was doing server package maintenance for Conectiva (which later became Mandriva) for 8 years. My focus was authentication, authorization and email servers. I also did a lot of security updates and announcements for Conectiva, you may find them in Bugtraq and other security mailing lists from back then (quick google search). For Conectiva, I maintained, among others: MIT kerberos and friends (pam-krb5), openldap and friends (pam-ldap, nss-ldap), cyrus-sasl, cyrus-imapd, postfix, samba.

• openldap dit: I tried to bring my openldap experience to Ubuntu with a small project called OpenLDAP-DIT (https://launchpad.net/openldap-dit, now recently moved to https://github.com/panlinux/openldap-dit), but it stalled as I was very much involved in Landscape and that had nothing to do with LDAP. I might resume it someday. At one of the Ubuntu UDSs it was even proposed to become the default DIT that Ubuntu would install and setup (https://blueprints.launchpad.net/ubuntu/+spec/server-maverick-openldap-dit).

• Landscape:
  • Landscape Autopilot: automated cloud deployments (openstack) using juju charms

  • automated troubleshooting of failed cloud deployments: together with Ursinha and Francis Ginther we created a cloud deployment log analyser. Hooked up to our jenkins CI, it would fetch logs from a failed cloud deploy and go over it looking for known issues. We had several signatures for known issues. If one was found, it would annotate the jenkins job so we would know right away why the deployment failed. Furthermore, we could use this to also keep the deployment up if an issue which we want to debug manually comes up. We called this "stop the test". Unfortunately it's a private project in LP (https://launchpad.net/autopilot-log-analyser) because it contains samples that have PPPA credentials and other secrets that were hard to remove.

  • Documentation and release notes: all Landscape release notes, including deployment guides, from https://help.landscape.canonical.com. For example, for the latest release 17.03:

    • https://help.landscape.canonical.com/LDS/ReleaseNotes17.03

    • https://help.landscape.canonical.com/LDS/JujuDeployment17.03

    • https://help.landscape.canonical.com/LDS/QuickstartDeployment17.03

    • https://help.landscape.canonical.com/LDS/ManualInstallation17.03

• Ubuntu Server Guide documentation fixes:

  • #1692259: slapd service does not automatically start

  • #973981: Ubuntu 11.10 help page for kerberos and ldap uses deprecated commands

  • #1038625: kerberos: never states to create non-admin user principal

  • #1170876: LDAP Private Key Access

  • #1239914: ldap installation Server guide implies for default settings that do not happen

  • #1409392: 'Kerberos and LDAP' instructions show bad ldap_kerberos_container_dn example

  • #1579209: Samba and LDAP is completely out of date

  • #1603540: wrong ldif file for altering indexes

Things I could do better

• When doing reviews, I find it hard to ask for changes when they could be seen as "nit picking". I cave in too quickly. Sometimes they are indeed "nit picking", but other times I feel like my request would improve the quality of a package or code. But then I think to myself "nah, I can do that myself later, let's unblock this MP".
• I need a better grasp of config file handling in maintainer scripts
• debconf is a mystery to me
• I'm still not 100% comfortable with the git workflow for merges. I get the idea, and I have done my own merges, but I find myself staring at merges done by others and there are things I just can't grasp yet why they were done that way. I need to do more merges of my own and get *different* people to review each.

Plans for the future

General

• Add DEP8 tests to the packages I'm familiar with
• Help make 18.04 an awesome LTS
• Make sure LTSs get bug fixes

What I like least in Ubuntu

Please describe what you like least in Ubuntu and what thoughts do you have about fixing it.

• LTS bugs really pile up I like doing SRUs, specially for LTSs, as that tells our users that we do care and we don't need them to keep updating to the latest and greatest version all the time.

• Some packages have 3 "initscripts": sysv, upstart and systemd. Which one is used can be complicated to find out. For example, see #170312 c9 where just the "reload" action from /etc/init.d (SysV) was taken and all other actions came from systemd. That's because the systemd service file didn't define a reload method. This needs cleanup.

• Sometimes we refrain from fixing a bug in Ubuntu because Debian also has the bug, and we rather have them fix it first and then sync than introduce or increase the delta we have with them. I think we should not be so afraid of the delta as long as we:

  • document it properly: DEP3 headers
  • have an expectation that it can be dropped soon
  • use the git workflow
  • file a bug with Debian including the patch, and upstream when that is the case
  • determine that the fix is important for our users and that further delays are not desired

• Many SRU bugs I see being accepted lack proper test cases. In many cases they are way too generic, or do not fulfill this requirement from the SRU template: these should allow someone who is not familiar with the affected package to reproduce the bug and verify that the updated package fixes the problem.

Comments

If you'd like to comment, but are not the applicant or a sponsor, do it here. Don't forget to sign with @SIG@.

Endorsements

As a sponsor, just copy the template below, fill it out and add it to this section.

TEMPLATE

== <SPONSORS NAME> ==
=== General feedback ===
## Please fill us in on your shared experience. (How many packages did you sponsor? How would you judge the quality? How would you describe the improvements? Do you trust the applicant?)

=== Specific Experiences of working together ===
''Please add good examples of your work together, but also cases that could have handled better.''
## Full list of sponsored packages can be generated here:
## http://ubuntu-dev.alioth.debian.org/cgi-bin/ubuntu-sponsorships.cgi?
=== Areas of Improvement ===