It turns out that using Jetty as the underlying servlet container would not work:
I would get an obscure Java exception during various operations:
1
Message /WEB-INF/jsp/settingsHeader.jsp(12,0) PWC6340: According to the TLD, rtexprvalue is true, and deferred-value is specified for the attribute items of the tag handler org.apache.taglibs.standard.tag.rt.core.ForTokensTag, but the argument for the setter method is not a java.lang.Object
Switching to Tomcat 8 worked.
Changing filesystem charset to UTF-8
I had been using ISO-8859-15 filenames for ever. As part of the OS ugprade,
I decided it was more than time to switch the whole system to UTF-8. (One
specific issue that prompted this was the fact that GDM now seems to not
support ISO 8859-15 GECOS user names anymore).
In order to have Subsonic properly handle file and directory names encoded
in UTF-8, I had to set LANG for it:
/etc/rc.conf.d/tomcat8
1
export LANG=fr_FR.UTF-8
and to re-create the database from scratch (remove everything from
/var/subsonic/db/exceptsubsonic.script).
Today I signed a GnuPG key using my air-gapped master private key,
and then tried to send the signature to the key owner from
my network-connected workstation using caff.
This failed miserably, with caff unable to find a valid signature,
and gpg --list-secret-keys missing the (stub) private key.
It turns out that I had inadvertently upgraded GnuPG on this workstation
to version 2.1.2, which has a completely revamped secret keys handling:
secret key material is now entirely handled by gpg-agent, and
the --secret-keyring command line option for gpg (which caff
depends on) is now
obsolete.
caff has been fixed
to support GnuPG 2.1. However this depends on GnuPG 2.1.3 or newer,
which is not in the ports tree yet,
so for the time being I have reverted
to the “stable” 2.0 release: portmaster -o security/gnupg20 gnupg.
For the past few months, Digikam
(and the underlying GPhoto2 library)
failed to connect to my Canon EOS 20D camera:
12345678910111213
canon/canon/usb.c (2): Initializing the (USB) camera.
canon/canon/usb.c (2): canon_usb_camera_init()
canon/canon/usb.c (2): canon_usb_identify: USB ID match 0x04a9:0x30eb (model name "Canon:EOS 20D (normal mode)")
gp_context_status (2): Detected a 'Canon:EOS 20D (normal mode)'.
Detected a 'Canon:EOS 20D (normal mode)'.
gp_port_usb_msg_read (3): Reading message (request=0xc value=0x55 index=0x0 size=1=0x1)...
gp_port_usb_msg_read (3): Read 0 = 0x0 out of 1 bytes USB message (request=0xc value=0x55 index=0x0 size=1=0x1) (empty hexdump of empty buffer)
gp_context_error (0): Could not establish initial contact with camera
*** Error ***
Could not establish initial contact with camera
gp_port_close (2): Closing port...
gp_context_error (0): An error occurred in the io-library ('Unknown error'): No error description available
Upgrading various components of my system did not help, so I ended up
suspecting a possible issue with the USB stack, which prompted a
major OS upgrade
from which I am still slowly recovering.
It turned out that the upgrade did not help. Further investigation and
debugging finally allowed me to zero in on the cause of the problem,
which turned out to be a bug in libgphoto2… which coincidentally
got fixed
hours before I identified it on my own.
I am leasing a Kimsufi dedicated server from OVH,
ks3269175.kimsufi.com aka 5.39.82.72. Since early
January 2015, TCP connections to that machine (and in
particular SSH connections) are sporadically hanging.
Analysis of the issue
This machine is on a network whose default router
is 5.39.82.254 (vss-gw-6k.fr.eu).
As far as I was able to determine, this is a virtual
router, load balanced using GLBP .
The two actual routers are:
vss-9b-6k.fr.eu, MAC address 00:07:b4:00:01:01
vss-9a-6k.fr.eu, MAC address 00:07:b4:00:01:02
When attempting to establish an SSH connection from the outside
to that machine, the first data packet in the connection
appears to be dropped if sent through 00:07:b4:00:01:01.
This does not appear to be related to any kind of stateful
firewalling system. As an experiment, I wrote a simple Scapy
script that loops sending identical TCP segments, one per second,
through both of the above MAC addresses, to a remote address
outside OVH.
A tcpdump on the dedicated server shows the stream of outgoing packets:
Now observing traffic on the remote machine, we see only those
packets that went through 00:07:b4:00:01:02:
123456
23:05:13.322004 IP 5.39.82.72.2222 > 194.98.77.4.60403: Flags [P.], ack 0, win 8192, options [TS val 123 ecr 456,eol], length 49
23:05:14.355176 IP 5.39.82.72.2222 > 194.98.77.4.60404: Flags [P.], ack 0, win 8192, options [TS val 123 ecr 456,eol], length 49
23:05:15.390245 IP 5.39.82.72.2222 > 194.98.77.4.60405: Flags [P.], ack 0, win 8192, options [TS val 123 ecr 456,eol], length 49
23:05:16.426968 IP 5.39.82.72.2222 > 194.98.77.4.60406: Flags [P.], ack 0, win 8192, options [TS val 123 ecr 456,eol], length 49
23:05:17.456869 IP 5.39.82.72.2222 > 194.98.77.4.60407: Flags [P.], ack 0, win 8192, options [TS val 123 ecr 456,eol], length 49
23:05:18.494918 IP 5.39.82.72.2222 > 194.98.77.4.60408: Flags [P.], ack 0, win 8192, options [TS val 123 ecr 456,eol], length 49
Resolution
None so far. OVH has been notified of the problem (TICKET#2015010719008317)
and all analysis elements in my possession have been conveyed to them,
to no avail so far: the machine has been essentially unusable for the
past two months and counting.
Update 2015-03-20 OVH say they identified a problem and are working on
a fix. No more SSH failure observed since 2015-03-18 in the afternoon,
so apparently the fix did work. Still waiting for a post-mortem explanation
as to what went wrong, and why it took them so long to ackonwledge,
investigate, and resolve the problem.
Update 2015-04-01 Service remains stable, in that failures are not
observed anymore. OVH indicates they are still discussing the underlying
issue with Cisco, and the fix is not completed yet.
Update 2015-06-17 Service remains stable. OVH indicates that they have
identified the origin of the issue, a fix is available, and they have
scheduled its deployment.
Update 2015-09-17 At long last, OVH confirmed that the problem is
indeed resolved on their side, and agreed to extend my subscription
by 3 months at no cost in compensation, which is decent of them.
Acknowledgements
Thanks to Pierre Beyssac for hinting at GLBP, and to Fabian at OVH
support for following up internally on this issue.
I endeavoured to upgrade my old FreeBSD 9.3-RELEASE system to brand
new 10.1. As expected, this was a quite bumpy process, and below are
a few things I had to find out the hard way.
Ports
Neither pkg update nor portupgrade can update all ports.
I had to dump all origins, remove all ports, then reinstall
everything manually.
Note that there's a know regression with syscons and kernel video
drivers: you can't switch back to a console once an X.Org session is
started. A new console driver called vt(4) fixes this issue while
bringing nice features. It's available in FreeBSD 9.3-RELEASE and
10.1-RELEASE but isn't enabled by default. To enable it, put the
following line in your /boot/loader.conf:
kern.vty=vt
It is a real shame that users essentially have no choice but
switching from the default syscons to the “new” (unfinished,
far from functionally complete) vt console driver.
The X mouse cursor occasionnally disappears for some unidentified
reason. Alt-Tab brings it back.
DRI
Both GDM and the GNOME desktop now require DRI access. At least
for ATI video cards, this means that user gdm, as well as anyone
logging in to a GNOME session, must have access to /dev/dri/card0:
/etc/devfs.rules linenos:false
1
add path 'dri/card0 mode 0666
GDM
Gdm won’t work out of the box (black screen):
gdm_lang cannot be set to a non-UTF-8 locale anymore
(if the month name in the current date contains an accent,
the greeter will abort). Time to bite the UTF-8 bullet, then.
Oh, and I can’t just remove the variable altogether, see below.
Keymap
Interesting issue for GNOME users. I found out that the GDM login screen
would always revert to US layout, no matter what. Initially I thought
the X server had an incorrect keymap due to HAL device enumeration,
so I added the following to my setup:
However this happened to be a total red herring, as by default the
port configures Xorg to use devd, not HAL. For devd, I
found out
this is achieved
using xorg.conf options:
But all of this was mostly irrelevant for my setup since I add
AutoAddDevices turned off in the X server setup, and the correct
layout was hardcoded in xorg.conf. And indeed,
starting it with startx yields the expected French layout.
However, it appears that gnome-shell considers that whatever keymap
is configured in the X server probably must be unsuitable, and
changes it on its own to a better default based on the current locale
(or “us” if no locale is set for gdm).
Printing
I am using an HP MFP1217nfw network printer, which requires the proprietary
print/hplip and print/hplip-plugin packages. These install print/cups as
a dependency. print/cups-filters is not installed as a dependency, but
is required anyway, or all print operations will fail with:
If