autofs function (5.0.7-3ubuntu3.2) can apparently be broken by enabling
DoS features in a TP-LINK TL-SG3424 switch, specifically the one
labelled "SYN sPort less 1024". This has turned out to be the problem
at my site. I'm not in a position right now to see if higher autofs
versions (5.1.1+) have
Problem still exists for 14.04 LTS, any chance we could
get the 5.0.8 version into the 14.04 LTS repo?
(sorry for the brevity, I'm having to edit this in Lynx,
because of side effects of the autofs problem, sigh)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which
Just upgraded to Wily here as well and I'm running into the failing
autofs too. Moving from ldap client to sssd is more dramatic than
desired here - how soon will the 1ubuntu3 be available in the Ubuntu
Wily repos? As of the time of this post, only 5.1.1-1ubuntu2 is
showing in the Wily repo.
--
This is generally a collection of multiple bugs in bash-scripted
completion functions that aren't correctly saving and restore the
current glob setting to allow setting old-style globbing temporarily for
their own use, much as IFS is typically handled. Disabling nullglob in
a user .bashrc is noth
I'd like to second Mutel comment that it's not the permissions that are
the problem, but the owner/group combo. At least one of them needs to
be daemon, it doesn't actually matter which (or both). Setting the
permissions to 0755 is a bad idea, since then any arbitrary process can
poke at the soc
Additionally, the window managers I've tried tend to get the "weird"
ones, which leads to all kinds of weirdness when you try to use keys
intercepted by the window manager for various things.
--
No Mouse/Keyboard since update and restart on evening of 4th August.
https://bugs.launchpad.net/bugs/
Just upgraded to Ibex, and I'm seeing problems that strongly correlate
to this bug. To xev(1) and xterm(1), all keys work as expected (I'll
call this "normal"), to xkeycaps(1), I see extremely different info,
which seems to reflect the same weirdness seen in xmodmap(1) -pk, (I'll
call this one "we
