Changes

• gitk: colour of remote refs
• myrepos: accumulated patches
• check-all-the-things: fix the yamllint cmd, add TODO items for haxelint and Dockerfile checkers, add checks for dodgy stuff, dead code, GIFs, Ruby (rubocop, roodi), Mono CIL binaries, FITS images and TeX
• gnome-shell-extension-show-ip: came up with the idea to fix the main blocker to deforking it, cleanups, show the primary IP address and show IP addresses in the menu
• Spelling:
  • codespell: broser, optionnal, optionnaly, reuest, ressource (hi samba folks), swtich, assumme(s), checg(ed), workes, accidentially, uninitalized, permision(s), whe, gruop(s), determing, imilar, tigthly, standar, iff, nott, technlogy, playble, redeable, diagnotic, langauage, mor, soundard, firmwware, containt(s), mazilla (hi malware authors), mozila, cilyndre(s), sepatae
  • lintian: broser, optionnaly, kenrel, swtich, assumme(s), checg(ed), workes, whe, gruops, imilar, tigthly, standar, iff, nott, technlogy, playble, debia, redeable, diagnotic, mor, soundard, firmwware, containt, mazilla, mozila, cilyndre(s), sepatae
• Wikipedia: Message-ID
• Debian wiki: AndroidTools, AppArmor/Contribute/Upstream, BSP/2017/05/ch/Zurich, CrossCompiling, DateTime, DebianEdu/Status/Stretch, DebianEvents/br/2017/MiniDebconfCuritiba/Atividades/CFP, DebianKernel/UserspaceTools, DebianMultimedia/FFmpeg (Unstripped), DebianRepository (Unofficial, UseThirdParty), DebianScience/UnofficialRepository, DebianUnofficial, dedup.debian.net, Derivatives/Census (QA (1, 2), Qubes, SparkyLinux), Exploits, fr/Simple-CDD, Games/Unsuitable, Hardening/RepoAndImages, Ideas/Ports, iMacG5, IRC, it/UltimateDebianDatabase, Merchandise, PaulWise/InterestingSoftware (1, 2), piuparts/FAQ, pkg-escience, qa.debian.org, QuickInstall, RepositoryLocal, Services/PublicUddMirror, Simple-CDD/Howto, SuitesAndReposExtension, SummerOfCode2006, SummerOfCode2014/Projects/DebianMetricsPortal, SummerOfCode2017/Projects/QA_BiologyApps, sv/IRC, SystemBuildTools, UltimateDebianDatabase, Vangelis Mouhtsis
• Debian website: Remove old unused and not working website hosting sponsor functionality (1 2 3 4 5 6 7), use correct SSL CA cert store, fix and https links to debian.ch and fix HTML entity escaping in the mirrors list (1 2)
• Debian ports: help rescue the #debian-ports IRC channel, remove dead mirror, update mirrors page, remove d-p.o reference, update bits.d.o and update packages.d.o
• Debian packages site: remove some git cruft
• Debian security tracker: remove NFU from webkit issue and add source link to DLAs
• Planet Debian derivatives: Add Qubes
• Debian package uploads: needrestart-session 0.3-4.1 and valgrind 1:3.10.0-4~bpo7+1

Issues

• Crashes in evolution, hexchat, gpaste, pidgin and eog
• Perl @INC issue in libthrift-perl
• Regression in samba-common-bin
• Debian migration unblocks of needrestart-session (1, 2)
• Debian Policy violation in selenium-firefoxdriver
• Important issue in needrestart-session
• Minor issues in gnupg and giflib-tools
• Features in file, debdelta, diffoscope, nss-passwords and linux

Review

• Spam: reported 5 Debian bug reports and 289 Debian mailing list posts
• Debian wiki: RecentChanges for the month
• Debian screenshots:
  • approved spectrwm (2), ranger, i3, kupfer, zathura (3), gimagereader, yubioath-desktop (3), fluxbox, libreoffice-writer, gtklp, terminator, wireshark-qt, wireshark-gtk, synaptic, empathy, gnome-control-center, shutter (2), gnome-online-accounts, gnome-documents, gnome-contacts, network-manager-openvpn-gnome, gnome-shell-extension-system-monitor, neofetch, octave-sparsersb, audacious, smplayer, bluefish, gpodder, delaboratory, geeqie, fracplanet and braillegraph
  • rejected hotssh (artefacts in screenshot), libsixel-bin (copied from elsewhere), spectrwm (not a screenshot) and geeqie (worse version of accepted image)
  • approved deletion (despite bogus reason) of snmp (screenshots site not a support forum, was a diagram not a screenshot)
  • rejected deletion of kupfer (we do not remove old versions), vlc (external UI in the screenshot is minimal), vokoscreen/fonts-ecolier-lignes-court (garbage in reason field), aptitude (discussing non-English screenshots with Christoph Haas), hydra-gtk (greetings are not valid reasons) and oxygen-icon-theme (the screenshot is not a reCAPTCHA)

Administration

• Debian systems: apply a patch to userdir-ldap, ask a local admin to reset a dead powerpc buildd, remove dead SH4 porterboxen from LDAP, fix perms on www.d.o OC static mirror, report false positives in an an automated abuse report, redirect 1 student to FAQs/support/DebianEdu, redirect 1 event organiser to partners/trademark/merchandise/DPL, redirect 1 guest account seeker to NM, redirect 1 @debian.org desirer to NM, redirect 1 email bounce to a changes@db.d.o user, redirect 2 people to the listmasters, redirect 1 person to Debian Pure Blends, redirect 1 user to a service admin and redirect 2 users to support
• Debian packages site: deploy my ports/cruft changes
• Debian wiki: poke at HP page history and advise a contributor, whitelist 13 email address, whitelist 1 domain, check out history of a banned IP, direct 1 hoster to DebConf17 sponsors team, direct 1 user to OpenStack packaging, direct 1 user to InstallingDebianOn and h-node.org, direct 2 users to different ways to help Debian and direct 1 emeritus DD on repository wiki page reorganisation
• Debian QA: fix an issue with the PTS news, remove some debugging cruft I left behind, fix the usertags on a QA bug and deploy some code fixes
• Debian mentors: security upgrades and service restarts
• Openmoko: security upgrades and reboots

Communication

• Invite GALPon MiniNo, Scibian, Roche Linux and ubilinux to the Debian derivatives census
• Welcome Qubes to the Debian derivatives census
• Start discussion about how many people contact the wrong part of Debian for their query

Sponsors The valgrind backport, samba and libthrift-perl bug reports were sponsored by my employer. All other work was done on a volunteer basis.

Michael and his daughter Marie

import apt
cache = apt.Cache()
cache["update-manager"].mark_install()
cache.commit()

4 comments Liked this article? Click here. My blog is Flattr-enabled.

• all my sponsors: Christoph Haas (haas) , Lo c Minier (lool), Free Ekanayaka (freee), Maximiliano Curia (maxy) and Micah Anderson (micah),
• my advocate: Matthijs M hlman (matthijs)
• my AM (who actually make it happen in a really short time frame, thanks a lot to him): Xavier Oswald (xoswald)
• all people who helped me during the process, to name a few: Christoph Berg (myon), Enrio Zini (enrico), Peter Palfrader (weasel)

/debian permanent link Comments: 5

Composite detected, disabling XDamage extension.
This is a workaround while XDamage extension does not work correctly with 3d desktops.
Hopefully it will work at next vino release.

industry-standard in IT infrastructure monitoring . Honestly it s a great tool but considering how many years it has been existing it barely evolved. During my diploma thesis I wrote an alternative software that I called MrNetwork that dealt with flaws that Nagios hasn t even fixed today. Still Nagios is a tool I have used for many years and it is very reliable.

• open source
• large community
• many powerful plugins (and own plugins are easy to create: just write a program that prints a one-line string and set a certain return code)
• easy-to-use web frontend
• debugging plugins is moderately simple.
  
• many thought-out features like host groups or notification options that make your life easier
  
• dependencies (so that you don t get 100 alerts if a router between the Nagios server and other servers went down)
  
• nagvis plugin with a great interactive editor that draws nice management-suitable graphs (although I found the ndo2db interface hard to set up at first and a little flaky)
  

• The focus is on availability checking you don t get fancy graphs on the values that are monitored (e.g how the CPU load was over time). So you ll need a second tool and set up the same checks there just to get graphs. But availability percentages are computed automatically.
• Textual configuration that has so many different settings that you need to look up the parameters often. A web-based configuration would probably be better (and is available as an add-on but I haven t tested it).
• Third-party plugins are often very badly programmed and barely documented that it appeared easier to reinvent the wheel. ( Look, ma, I can has plugins. )
• Some views on the web interface are not very obvious (e.g. clicking on the title of a host group gives a nice view of all hosts with all services).
• Many plugins don t have corresponding configuration entries so you have to find out how they work and write configuration entries yourself (and those which are preconfigured take some archeology to find out which parameters they expect). This is a huge time-waster for beginners. And in your services configuration you have to verify your checks configuration to understand the meaning of each parameter. Or do you remember what check_http 80!john!doe!10!30!body is supposed to check?
• Every set of parameters of a certain plugin requires a distinct configuration entry. The plugins have dozens of configuration switches that you may need one day. Want to set a timeout on HTTP checks? Write another check configuration. Want to check for a certain string in the HTTP response? Write another check configuration. And so on.
• Most checks are run from the Nagios server itself (the NRPE plugin to do the checks on the respective remote systems somehow refused to work properly here) which is suboptimal and puts a lot of load on the server.
• By default every alert triggers a notification. So if you can t define proper dependencies (e.g. if you want to check your web server in all 30 supported languages and there is some logical error) then you will get spammed with alerts.

• very quick to monitor a large set of similar devices once the general device class is defined
• simple web interface
• very reliable
• can monitor SNMP values (it does this very well) or execute external scripts thus can be easily extended
• flexible graphing you can sum up values of two graphs into a new graph (aka mtargets multiple targets)
• different check frequencies can be configured for different subtrees through cron (by default values are collected every 5 minutes this can be set as low as one minute if needed)

• the textual configuration is error-prone (leading to funny Perl errors that can be hard to debug)
• users may expect to see all parameters of a certain device instead of all devices having a certain parameters ( Give me the statistics of router42 instead of Let s see the temperature of all routers we have. )
• customizing the graphs (drawn by RRD tool) isn t trivial
• Frequency of checks is by default 5 minutes. Before RRD can draw the first value of a graph it needs three values. So you ll be waiting 15 minutes before you see any results.
• RRD rounds data by default. So the yearly graph doesn t show the peaks that the daily graphs do. (This can be fixed by not graphing the average values but the maximum values.) Long-time archiving of graphed data is not possible without throwing away the RRD files and manually customizing them. Changing the monitoring frequency (aka heartbeat ) is not possible either without throwing away the data and starting from scratch either.
• No proper built-in alerting in case certain thresholds are exceeded.

• Beautiful and (for most features) simple web interface. Nice features like graphs that can be zoomed using Javascript.
• Fine-grained permissions system. So a certain user may get read-only access to a certain subtree.
• The tree where graphs are placed can be configured freely so you get exactly the view you want.

• Doesn t hide the RRD magic very well. The user is easily confused by templates, data sources and the like.
• Graphing sometimes just stops working for no reason or values are missing although the server isn t overloaded and other software doesn t show such outages. According to a quick search on the lazyweb I m not the only one with such effects.
• Setting up many systems means a lot of clicking in the web interface. Setting up new kinds of checks (aka templates ) means even more clicking and is very error-prone.
• The quality of some third-party templates I tested was pretty bad. Creating new templates is tedious, error-prone, frustrating and close to black magic. Nothing for the casual user at least.
• Doesn t handle SNMP correctly (this is the biggest fail in my opinion and makes it unusable here). Although it knows how to query indexes (e.g. ifDescr to get the names of your network interfaces) it just seems to stored fixed OIDs. So once the SNMP tables change the order or number of items (which isn t unusual) then suddenly other parameters get graphed.
• Frequency of checks is by default 5 minutes. Increasing the frequency leads to missing data and wrong results.
• As it uses RRD and needs 3 valid values you won t see that your monitoring fails until you wait 3 5=15 minutes. Not suitable for impatient non-smokers like me.
• Debugging failed checks is close to impossible. If a check fails then I find myself clicking around randomly trying to find typos because the alternative is digging around in database entries.
• The web interface is sometimes confusing. A refresh of SNMP tables is done by clicking a unmeaning green circle icon. Adding new items to a list is done by clicking an inconspicious Add link that doesn t even look like a link.
• Another UI confusion: graphs are created from the devices view. But they are deleted from the graph management view.
• No alerting in case certain thresholds are exceeded. Another tool like Nagios would still be needed to notify you.
• Can t sum up multiple targets so monitoring failover clusters doesn t work well.
• RRD averages data when putting daily values into weekly values, weekly into monthly and monthly into yearly. So the yearly graph doesn t show the peaks that the daily graphs do. (This can be fixed by not graphing the average values but the maximum values.) Long-time archiving of detailed graphed data is not possible (RRD). Changing the monitoring frequency (aka heartbeat ) is not possible either without throwing away the data and startin from scratch.

• Beautiful web interface
• Nice gimmicks like google maps integration to show you where your servers are down worldwide. Only makes sense when monitoring networks with several/many remote locations.
• Can partly discover parameters of systems automatically. That works for static routes (although I wonder why the heck I want to monitor static routes), file systems and network interfaces. On the other hand processes can t be discovered automatically and have to be set up manually.
• Does not come with a specific agent but plays rather well with plain old SNMP.
• Can monitor Windows through native WMI.
• Large fanbase.

• Web interface feels slow (Zope is bloated)
• Opaque operation. It does not tell what s actually going on. You can add monitoring and check back later if anything worked they way you want.
• Questionable reliability. In a test here I was monitoring a running process. The process was said to be down and suddenly went to up after a while although nothing had changed on the system.
• Just one dashboard. Several dashboards similar to Zabbix screens would be nice.
• Configuration and data is spread across MySQL, the internal Zope database storage and RRD files on disk.
• The dependency graph is a nice Flash-based applet displaying how the systems are connected. But it does not show any details about the systems aside from whether they are up or down. And clicking on a host does not take you anywhere but center on the system. Beautiful but it could do so much more than just look beautiful.
• I dislike the way that things are configured. The context menu with the down arrow needs to be used. I d prefer simple add or delete actions instead of navigating the menu all the time. Looks like Javascript is used wrongly here.
• Limited open-source version. Full version needs to be paid for.

• Availability Monitoring (like Nagios) and graphing (like Cacti) is combined into one tool.
• Highly configurable. User John may just get an SMS for problems of high severity during the weekend and on weekdays get a Jabber message. Even automatic actions like restarting services can be set up.
• The notifications actually help the person who gets the message. Low disk space on /var on web5 with an additional comment is pretty helpful even when sent via SMS.
• Very performant. The remote agent gathers the information on each system.
• Fast web interface.
• Sophisticated monitoring of web sites. Zabbix can follow a path of simulated mouse clicks on a web site and check for functionality and response time.
• Real-time graphs. Values are by default collected every 30 seconds. You quickly see where you are going.
• Permissions system. Certain users can be limited to certain views.
• Gathered data is stored in a database (MySQL, PostgreSQL, SQLite) instead of an RRD file. Storage periods (aka history ) can be configured freely. Backup up the database is all there is to be done.
• Agent for remote checks simply works (and is available on Debian Lenny) and can even call scripts or shell one-liners to gather information. The agent can gather a lot of information locally and send it to the Zabbix master server. Works on several operating systems and even on Windows (just set up monitoring of Windows services and processes successfully).
• Templates (that can even link to further templates) save time in setting up many checks.
• Graphs (plots of values over time) can be customized like which items are plotted and in what way. Even pie charts are possible.
• Even the parameters that don t get an explicit graph can be graphed at any time. E.g. the agent has tracked the CPU load on a system that you never cared about then you can graph that with one mouse-click.
• Screens and slide shows can be used for high-level views (aka dashboards ) or to be displayed on a big geeky display. They can combine textual display of the status as well as clocks, ad-hoc graphs or predefined graphs.
• Very flexible trigger expressions. For example you can tell a trigger to fire if the average system load over the last 15 minutes is above a certain value. As all measured parameters are stored in a backend database you can use all kinds of mathemical expressions. Like firing a trigger if the average number of running processes during the last half hour is above 50. All other software I tested just has access to the last value gathered.
• Customized alerting is simple through shell-based alert scripts.
• Remote monitoring made easy by using a Zabbix proxy.
• Paid support and paid custom programming available. But the software is completely open-sourced.
• 320 page PDF manual with screenshots and nice references. (Although I d personally prefer an online help. Currently the ? link within the web interface just points to the PDF that you can download.)

• A lot of mouse moving and clicking is required to set up things. For example setting up an alert if the free space on a disk on a certain server is getting too low then you need to set up hosts, items, triggers and actions. Some of the clicking seems redundant. E.g. I didn t find a way to create triggers automtically for a set of checks. If I monitor how full the /home partition is then I d like to set a threshold in the same configuration step.
• Takes a little patience understanding the concepts although they make sense after half a day.
• The web interface is crammed full of features. For casual users it s confusing to navigate.
• The map editor is close to unusable. You can put icons and connections into the graph but have to define the X and Y coordinated manually. This feature is nice but desperately needs a good interactive map editor like nagvis uses.
• Does not detect the available assets in a monitored server automatically. Imagine that you want to monitor the space on all disk partitions on a system. You will have to copy over or create the check items manually or define all possible checks in a template and disable those you don t need. Cacti handles that better by offering you a list of partitions to monitor. Zenoss can do that partly. The zabbix agent should be able to handle such a service discover automatically. (The built-in Discovery feature rather seems to detect new servers in a given network range automatically. But that s something different.)

• #nagios: 133 users
• #cacti: 58 users
• #cricket: 2 users
• #zenoss: 54 users
• #zabbix: 61 users

• psql -h localhost bacula admin -c “COPY basefiles (baseid,basejobid,jobid,fileid,fileindex) FROM ‘/var/tmp/BaseFiles.txt’”
• psql -h localhost bacula admin -c “COPY cdimages (mediaid,lastburn) FROM ‘/var/tmp/CDImages.txt’”
• psql -h localhost bacula admin -c “COPY client (ClientId,Name,Uname,AutoPrune,FileRetention,JobRetention) FROM ‘/var/tmp/Client.txt’”
• psql -h localhost bacula admin -c “COPY counters (Counter,MinValue,MaxValue,CurrentValue,WrapCounter) FROM ‘/var/tmp/Counters.txt’”
• psql -h localhost bacula admin -c “COPY device (DeviceId, Name, MediaTypeId, StorageId, DevMounts, DevReadBytes, DevWriteBytes, DevReadBytesSinceCleaning ,DevWriteBytesSinceCleaning, DevReadTime,DevWriteTime, DevReadTimeSinceCleaning, DevWriteTimeSinceCleaning, CleaningDate, CleaningPeriod) FROM ‘/var/tmp/Device.txt’”
• psql -h localhost bacula admin -c “COPY file (FileId, FileIndex, JobId, PathId, FilenameId, MarkId, LStat, MD5) FROM ‘/var/tmp/File.txt’”
  psql -h localhost bacula admin -c “COPY fileset (FileSetId, FileSet, MD5, CreateTime) FROM ‘/var/tmp/FileSet.txt’”
• psql -h localhost bacula admin -c “COPY filename (FilenameId, Name) FROM ‘/var/tmp/Filename.txt’”
• psql -h localhost bacula admin -c “COPY jobmedia (JobMediaId, JobId, MediaId, FirstIndex, LastIndex, StartFile, EndFile, StartBlock, EndBlock, VolIndex, Copy) FROM ‘/var/tmp/JobMedia.txt’”
• psql -h localhost bacula admin -c “COPY location (LocationId, Location, Cost, Enabled) FROM ‘/var/tmp/Location.txt’”
• psql -h localhost bacula admin -c “COPY locationlog (LocLogId, Date, Comment, MediaId, LocationId, NewVolStatus, NewEnabled) FROM ‘/var/tmp/LocationLog.txt’”
• psql -h localhost bacula admin -c “COPY log (LogId,JobId,Time,LogText) FROM ‘/var/tmp/Log.txt’”
• psql -h localhost bacula admin -c “COPY media (MediaId, VolumeName, Slot, PoolId, MediaType, FirstWritten, LastWritten, LabelDate, VolJobs, VolFiles, VolBlocks, VolMounts, VolBytes, VolErrors, VolWrites, VolCapacityBytes, VolStatus, Recycle, VolRetention, VolUseDuration, MaxVolJobs, MaxVolFiles, MaxVolBytes, InChanger, MediaAddressing, VolReadTime, VolWriteTime, EndFile, EndBlock, LabelType, StorageId, VolParts, MediaTypeId, DeviceId, LocationId, RecycleCount, InitialWrite, ScratchPoolId, RecyclePoolId, Enabled, Comment) FROM ‘/var/tmp/Media.txt’”
• psql -h localhost bacula admin -c “COPY mediatype (MediaTypeId, MediaType, ReadOnly) FROM ‘/var/tmp/MediaType.txt’”
• psql -h localhost bacula admin -c “COPY path (PathId, Path) FROM ‘/var/tmp/Path.txt’”
• psql -h localhost bacula admin -c “COPY pool (PoolId, Name, NumVols, MaxVols, UseOnce, UseCatalog, AcceptAnyVolume, VolRetention, VolUseDuration, MaxVolJobs, MaxVolFiles, MaxVolBytes, AutoPrune, Recycle, PoolType, LabelFormat, Enabled, ScratchPoolId, RecyclePoolId, LabelType, NextPoolId, MigrationHighBytes, MigrationLowBytes, MigrationTime) FROM ‘/var/tmp/Pool.txt’”
• psql -h localhost bacula admin -c “COPY storage (StorageId, Name, AutoChanger) FROM ‘/var/tmp/Storage.txt’”
• psql -h localhost bacula admin -c “COPY unsavedfiles (UnsavedId, JobId, PathId, FilenameId) FROM ‘/var/tmp/UnsavedFiles.txt’”

• Uploading is done through HTTP PUT directly in debexpo, and handled immediately. This means that packages can be available within seconds of you uploading the package instead of having to wait for a cron job running an importer.
• debexpo supports plugins for several stages of package life-cycle. The main use of these are for QA purposes on the package, such as automatically running Lintian, checking the watch file, or checking bugs closed actually belong to the package in question, but there is scope for much more. Plugins are easy so you can customize a repository to check for whatever you want. Other cool plugins allow features such as pulling an orig.tar.gz from Debian if it is absent from the upload and not in the repository already. Plugins provide you the option to customize your repository for any purpose.
• Users will be able to have their own personal repository (much like Launchpad’s PPAs) to host binary packages. This is simply achieved by creating a new user, uploading, and adding the appropriate entry to your sources.list.
• Sponsors will be able to tell debexpo what kind of packages he or she likes to see, and a filtered package list will be shown. These kind of filters will include whether it’s a python package, or C library, whether it uses CDBS or straight debhelper, or even whether the maintainer is in the New Maintainer process (this is clearly a mentors-specific feature).
• Packages will be able to be commented on by other users, in the same way as Ubuntu’s REVU tool. This keeps package discussion in one place, and Debian Developers can claim to have uploaded the package. This is useful to stop the scenario of a Debian Developer reviewing a package that has requested a sponsor, and then finding the package has been uploaded already after the initial uploader left no mention of this.
• And more to come.