Paul Wise: Some thoughts on using Debian
I'm currently running Debian's rolling release (aka "testing") on my main
machine and have added some stuff to make that nicer.
First thing I have is configuration and package management.
Since I have relatively few machines, I am using a metapackage per machine that
installs some configuration files with changes that I want.
The metapackages depend on packages that I need installed so that I can mark
all other packages as being automatically installed.
The metapackages are also useful for documenting why I have things installed.
It depends on things like task-laptop from tasksel, hardware support packages,
the GUI I use, games I play often and so on.
My laptop does not have a CD/DVD drive so I have some metapackages to fool
apt into ignoring dependencies on CD/DVD related packages I don't need.
I'm building the metapackages using equivs-build and a small Makefile.
I use the File: header supported by equivs-build for installing config files.
I have popcon installed and enabled but I don't want it to leak the names of the
metapackages so I have added a prefix to my metapackages and modified
the popcon cron job to remove anything containing that prefix.
I also don't want apt to ever remove the metapackages so I mark them as
Important: yes and configure apt to never autoremove them.
--- /etc/cron.daily/popularity-contest~
+++ /etc/cron.daily/popularity-contest
@@ -71,8 +71,8 @@
# try to post the report through http POST
if [ "$SUBMITURLS" ] && [ "yes" = "$USEHTTP" ]; then
for URL in $SUBMITURLS ; do
- if setsid /usr/share/popularity-contest/popcon-upload \
- -u $URL -f $POPCON 2>/dev/null ; then
+ if grep -v myprefix- $POPCON setsid /usr/share/popularity-contest/popcon-upload \
+ -u $URL 2>/dev/null ; then
SUBMITTED=yes
else
logger -t popularity-contest "unable to submit report to $URL."
@@ -94,7 +94,7 @@
echo "MIME-Version: 1.0"
echo "Content-Type: text/plain"
echo
- cat $POPCON
+ grep -v myprefix- $POPCON
) do_sendmail
SUBMITTED=yes
else
/etc/apt/apt.conf.d/99metapackages:
APT::NeverAutoRemove "^myprefix-.*"; ;
I am using Raphael Geissert's mirror redirector in order to automatically
use up-to-date and hopefully non-broken mirrors.
Unfortunately this often causes apt to complain about hash sum mismatches
and then proceed to forget about all packages.
I work around this by always running apt-get update in a loop until it succeeds.
while ! apt-get update ; do sleep 1m; done
A lot of the time I need to install packages from outside of testing.
So my sources.list contains lines for testing, unstable and experimental.
I have some apt pinning so that by default I only have packages from
testing but if I manually upgrade some packages to unstable or experimental,
then I will get upgrades within that suite until those packages migrate down to
unstable or testing.
The apt pinning needs priorities between 1000 and 500 for this to work nicely.
I also pin some things like lintian, debian-policy and devref
to unstable/experimental since having old versions of those is not useful.
/etc/apt/sources.list:
# testing
deb http://security.debian.org/ testing/updates main contrib non-free
deb-src http://security.debian.org/ testing/updates main contrib non-free
deb http://http.debian.net/debian/ testing main contrib non-free
deb-src http://http.debian.net/debian/ testing main contrib non-free
# unstable
deb http://http.debian.net/debian/ unstable main contrib non-free
deb-src http://http.debian.net/debian/ unstable main contrib non-free
# experimental
deb http://http.debian.net/debian/ experimental main contrib non-free
deb-src http://http.debian.net/debian/ experimental main contrib non-free
/etc/apt/preferences.d/system:
Package: *
Pin: release a=testing
Pin-Priority: 800
Package: *
Pin: release a=unstable
Pin-Priority: 700
Package: *
Pin: release a=experimental
Pin-Priority: 600
/etc/apt/preferences.d/packages:
Package: lintian
Pin: release a=unstable
Pin-Priority: 900
Package: lintian
Pin: release a=experimental
Pin-Priority: 910
Package: debian-policy
Pin: release a=unstable
Pin-Priority: 999
Package: developers-reference
Pin: release a=unstable
Pin-Priority: 999
I have a few configuration files and a cron job to make all programs dump
core files when they crash so that I can file bugs, even for random crashes
that are not easy to reproduce.
I enabled some kernel settings with sysctl,
lifted some security limits to enable core dumps,
and added a cron job to delete old core dumps and
notify me of new core dumps.
In my shell configuration I also turn on two glibc options to cause
programs to crash when they have improper memory management.
I also have a second machine I use for bug discovery where I have lots of stuff
installed and everything apt pinned in the opposite way; experimental > unstable > testing.
When I have time I use this machine to do testing of packages I use, classes of
packages that I care about (such as games) and sometimes packages I do not use.
/etc/sysctl.d/corefiles.conf:
fs.suid_dumpable = 1
kernel.core_uses_pid = 1
kernel.core_pattern = /var/cache/corefiles/core-%p-%u-%g-%s-%t-%h-%e
/etc/security/limits.d/corefiles.conf:
* soft core unlimited
* hard core unlimited
/etc/cron.daily/corefiles:
#!/bin/sh
mkdir -p /var/cache/corefiles
chmod 2777 /var/cache/corefiles
if [ $(find /var/cache/corefiles -mtime +100 -a ! -type d wc -l) -gt 0 ]; then
echo deleting:
find /var/cache/corefiles -mtime +100 -a ! -type d
find /var/cache/corefiles -mtime +100 -a ! -type d -print0 xargs -0 rm -f
fi
if [ $(find /var/cache/corefiles ! -type d wc -l) -gt 0 ] ; then
echo still present:
find /var/cache/corefiles ! -type d
fi
~/.bash.d/malloc:
export MALLOC_CHECK_=2
export MALLOC_PERTURB_=$(($RANDOM % 255 + 1))
I unfortunately need some packages from contrib/non-free, so
I have a cron job to let me know when I accidentally install new packages from
contrib/non-free.
@daily diffcmdoutput ~/.cache/non-free-contrib aptitude search ~i~snon-free\ ~i~scontrib
I backup my dpkg package selections and debconf databases.
@daily diffcmdoutput ~/backup/packages dpkg --get-selections
@daily diffcmdoutput ~/backup/config debconf-get-selections 2> /dev/null
I notify myself of changes to the list of new packages so that I can review them,
install any useful/interesting ones and tell aptitude to forget them all.
@daily diffcmdoutput ~/.cache/new aptitude search ~N
I notify myself of changes to the list of packages I have installed that are not
up-to-date packages from testing.
This helps me catch packages removed from testing/unstable/etc that I use.
@daily diffcmdoutput ~/.cache/apt-show-versions sh -c "apt-show-versions grep -v '/testing uptodate'"
I notify myself of packages that I maintain that are having issues migrating to testing.
I considered doing the same for teams I am involved in but they aren't particularly
functional teams so there would be a lot of noise.
@daily grep-excuses 'Paul Wise'
I notify myself of RC bugs that apply to testing and are installed.
The list is so long that it just makes me depressed instead of
motivated to help fix RC bugs so I only notify myself of changes.
Even then I rarely do anything other than delete the notifications.
If you are looking for ways to help Debian, fixing RC bugs is a great choice.
@daily diffcmdoutput ~/.cache/rcbugs rc-alert -d T --exclude-tags IP+MR
I notify myself of packages that are orphaned or need a new maintainer.
There are usually so many packages in this list that it is not useful,
so I only notify myself of changes to the list.
I rarely adopt packages because I feel overloaded already.
If you are looking for ways to help Debian, adopting packages is a good choice.
@daily wnpp-alert --diff
One of my packages is for interacting with servers on the Internet,
so I need to run tests periodically to ensure the package works.
I do that with a simple Makefile but maybe I need to move to
autopkgtest, need to find out if it saves data between runs first.
@monthly cd ~/devel/debian/tests ; make
I install debsecan so that I get notified of security updates in unstable
and new security issues that are not fixed yet.
The way debsecan works is that it notifies about changes in security issues
and updates and also includes a full list of all known unfixed issues.
I generally install security updates from unstable when I see them.
The list of unchanged issues is so long that it makes me wonder
how many times I've been cracked already.
The oldest issue goes back to 2002 but most of them are 2010 or later.
The various parts of WebKit are by far the worst security offenders.
I don't bother with the white-listing functionality due to the
quantity of security issues and because it isn't possible to
add a comment about each white-list item.
If you want to get involved with the security team, reporting issues
with the data in the security tracker is a good idea.
I subscribe to the ftpmaster RSS feeds for new and removed packages
to keep up to date with changes in the archive.
A lot of the above applies to running systems based on Debian stable too.
If you have any other thoughts about running Debian systems, please blog about them.
The diffcmdoutput command used above is a simple shell script:
#!/bin/sh
cache="$1"
shift
temp="$(mktemp "$cache"XXXXXXXXXXXXXX)"
"$@" > "$temp"
diff --unified "$cache" "$temp"
mv --force "$temp" "$cache"
[1]
I ve been a wannabe GTD afficionado for some years. I ve wanted to do it,
but managing lists has always been something that has too much friction,
overhead, or whatever. Finally, though, I think I might have found a way to
manage lists that works.
My use-case isn t unique, although I will concede I m perhaps being more
dogmatic than most. I want something that:
This blog, together with
I've had a few weeks with very little time spent on Debian. I did set aside
some time to try to find and fix an RC bug, to help the release. Steven C
commented to let me know about the
A few days ago,
Synaps
Synaps is written in around 7k lines of Python (with 28 % of which are
comments), reuses at least one common module of OpenStack
(openstack.common.cfg) and copy some modules from Nova. One thing that
strikes me, is that there seems to be only a few unit tests compared to most
OpenStack projects. Also, many parts of the code and documentation contains
text written in korean, which won't be very helpful for most people! :-)
It uses some external technologies, like
Overlap with Heat
For now, there's not a lot of overlap with Heat, because Heat does not
implement completely the CloudWatch API. Heat actually still misses a lot of
the CloudWatch functions. But as soon as it will implement the CloudWatch
API completely, the overlap will be complete with Synaps in this regard.
One divergence point however, is that Heat uses RPC to access data from the
storage back-end via its engine (the central daemon), whereas Synaps
directly connects to Cassandra. Also, Heat relies on SQLAlchemy, like most
OpenStack projects needing a database.
Overlap with Ceilometer
One of the goal of Ceilometer is to provide data probes and pollsters for
all OpenStack components (Nova, Swift, Quantum ) whereas Synaps let the
OpenStack users to put any kind of metric inside it, and therefore doesn't
provide anything for now.
But the storage of metrics is the main common point between Synaps and
Ceilometer. Synaps chose only one technology, Cassandra, to store its
metrics, whereas Ceilometer took care of building an abstraction layer for
the storage engine. Ceilometer currently allows an operator to use SQL or
MongoDB, but Cassandra could likely be added.
Data metric consolidation is done by Synaps. This makes sense, since Synaps
don't need to have the full data history to trigger alarms. On the opposite,
Ceilometer needs to have a full history to allow things like billing, and
don't do any aggregation on data.
Also, in Synaps, the data analysis is done using Pandas. This means the data
used are retrieved from the Cassandra back-end, and then transformed by
Pandas inside Synaps in something else. It's likely that in such a case,
Synaps should use CQL to achieve that. Ceilometer manipulates the data near
their storage: it means that the computation are done by back-end to be
efficient (SQL, mapreduce ).
Conclusion
Considering Samsung open-sourced Synaps late in the development process, I
don't feel like they aimed to have it becoming a core component. This is
always sad, because the effort put into this implementation are big and it
would have probably little to add some abstraction layers to follow what
other OpenStack projects do. But this takes time and energy, and it's
understandable that Samsung didn't want to achieve this in a short time
frame.
There's a part of the code and architecture that overlaps with Ceilometer
and Heat. Ceilometer is becoming a specialized point to store data metrics
from any source: so it's sad, but understandable, that Synaps did not tried
to reuse it. Fortunately, Heat is working with Ceilometer to achieve exactly
that. This means OpenStack would have only one metrics storage point, used
for billing, for monitoring and alarming.
Therefore, I think Synaps is an implementation of CloudWatch that should be
looked at as an inspiration for Heat and Ceilometer to build a better and
more integrated solution!
Christopher
as zack has
That was not my target in today's marathon (my second one in the
year). The target was breaking my 3h38'45" record, set on June 10th in
Caen.
And, well, I did it. By more than 5 minutes \o/. Of course, the
According to the release manager of Ubuntu the

I want all my computing environments "furnished" similarly and as close
to my personal taste as possible - be it big and small machines,
self-administered and user accounts of others.
and not only for myself - similar is needed for the environments I
help maintain for my friends
Yesterday I went to