Unfortunalety this is the second time in the row, that we seem to be short of manpower while preparing the booth. Actually just one person was able to commit his available time. A general offer was announced by 3 people (including me). This makes me a little sad, cause CLT is a very community driven event which is really nice organized. I always liked to chat and discuss with very interesting people from other projects and visitors.
Some of our customers are using central CUPS systems for managing their printer infrastructure. In the last years the demand for support printing (called Airprint) from mobile apple products increased. This worked well for us on Debiansqueeze as documented here (updated scrips).
I tried this on a fresh installed Debian wheezy amd64, but no printer was found on any IOS device.
Hmm …. let’s see if the printer is announces via avahi:
$ avahi-browse -a | grep -i print
+ eth0 IPv6 Kyocera FS-1020D @ service Internet Printer local
+ eth0 IPv6 AirPrint Kyocera @ service Internet Printer local
+ eth0 IPv4 Kyocera FS-1020D @ service Internet Printer local
+ eth0 IPv4 AirPrint Kyocera @ service Internet Printer local
WTF?!? Fortunately we have an Ubuntu 12.04 running in our office and printing from IOS devices works without problems (without copying any files to /etc/avahi/services/):
$ avahi-browse -a | grep -i print
+ eth2 IPv6 Ricoh Aficio MP C2800 @ printing Internet Printer local
+ eth2 IPv6 Ricoh Aficio MP 171 @ printing Internet Printer local
+ eth2 IPv4 Ricoh Aficio MP 171 @ printing Internet Printer local
+ eth2 IPv4 Ricoh Aficio MP C2800 @ printing Internet Printer local
I just copied the whole configuration over to my wheezy system, but it didn’t worked out. I tried this all on a kfreebsd-i386 system again without success. Sorry, but I don’t understand the source of this issue. Cups on wheezy has the same upstream version as on precise. Avahi-daemon on wheezy is just one minor version ahead off precise. Is this a bug/incompatibility in cups and/or avahi? A missing patch compared to the packages of precise? Is this a configuration problem?
Update: Looking into LP #1054495 and the debdiff of cups 1.5.3-0ubuntu6 indicates, that there seems modifications beside simple changes of mime configurations files.
Update: The fix for LP #1054495 does really fix the problem on wheezy too. With the help of Didier Raboud I was able test a binary package with this fixapplied on our test setup. The good news is, there are no extra modifications needed beside just configuring cups to export it’s printers for enabling support for iOS devices. I opened #700961 and hopefully release managment will accept this fix for wheezy.
Hints, rants and comments could be send to ‘blog - at - waja - dot - info’ or via @blogwajainfo.
We are searching a motive for a painting or a painting itself for a quite while now. This should find it’s place in our living room.
Unfortunately we didn’t found one, which matched our both prospect and/or wasn’t compatible with the rest of our living room.
Yesterday we stumbled upon a motive which was quite nice, but was too small and it was neighter possible to get it in a bigger size nor to find out who was the origin painter of the picture. Now we are searching for the name of the picture and/or the painter.
Any hints appreciated at ‘blog - at - waja - dot - info’. A photo with higher resolution can be found here
Update: Okay … an unknown people (many thanks) hinted me, that google image search is the tool that could be very usefull. Google revealed that the painter is Inna Panasenko.
P.S. Is it noticeable that I’m in vacation mode? ;)
Today we where packing back our holiday decorations into boxes. We also had a music box to put away.
Do you see the defect in the picture? ;) No? Okay … some years ago my oldest daughter broke it into some pieces and a friend of us (Hi muempf! ;) did glue all together. When he showed us the nice music box, it was recovered very well, but one detail was changed from original. One horseman wasn’t reassembled as the other onces.
If you you didn’t found the defect, please have a look here.
You had fun with this? Maybe this is another one for you, I took that photo on christmas eve when my youngest daughter had placed her new ‘Lisa Plastic’:
Today short before ending business hours I was noticed that there is a problem with a server system (domU). Login with unprivileged user was possible but using “su” didn’t worked, also login in as root via privkey failed. Fortunately I was able to connect via xen console and login via tty. Looking into the bash history the reason revealed quickly:
Usually I’m monitoring stuff with Icinga (Nagios in the past). But for my small network, I primary needed monitoring of bandwidth.
In our commercial environment we are using a closed source software for accounting traffic. There is also a license for testing purpose with a reduced number of sensors available. But I’m neither running windows in this network nor feeling happy with this.
Cacti is a bit bloated for this small network and zabbix is (caused by what?) removed in wheezy, beside that I’m not getting the concept behind it. So I thought I could give munin a try and on the first view it doesn’t look so bad. Monitoring my half dozens openwrt devices works like a charm by installing muninlite just the package.
One central part of the network is a QNAP TS-459 Pro+, hosting a BackupPC and TimeMachine service, proving SMB/AFS data store and running SqueezeBox Server for another half dozen streaming devices. Unfortunately there is no optware package to provide a munin node. So I just copied the shell script of muninlite and the xinet config over from an openwrt device. At first it looked not bad, but than munin wasn’t able to collect the data. After a while I realized, that munin was failing when collecting the network informations. A look into the muninlite script revealed that it was failing when trying to discover the interface speed of eth1 via ethtool.
In my setup the QNAP is just connected with with one network interface, the second one is unconnected. Unfortunately all network interfaces on QNAP devices are up and therefore listed in /proc/net/dev where muninlite is discovering the network interfaces:
Today I planed to move my FTP server to a new system running Debianwheezy. Usually I’m running vsftpd, so this was also the plan for the new host. As this system is dual stacked, I wanted to offer the service on IPv6 too.
On the old system I started vsftpd via xinetd, as far as I remember was vsftpd in squeeze not able to bind on the IPv4 and the IPv6. Anyways … I didn’t wanted to use any inetd system … So I looked if there is any way to solve that.