[Bug 112909] Re: Support extended attributes
What is the status on this? I just started using the calendar server package and quickly discovered that I've adopted a ticking time bomb; backups will be completely useless if the extended attributes are not preserved. I want to do an ext4 reformatting and fresh install of my server, porting much of my existing configuration/data onto it. But the unsatisfied need to copy xattr metadata to another physical location is an arcane hindrance reminiscent of Linux in 1992. It seems almost embarrassing to think there might actually be no feasible way to accomplish such a basic and necessary task. Are there even any workarounds floating around, like a bash or perl script that recursively copies directories and then copies the metadata, or recursively extracts the metadata from a directory and then re- applies it to another directory with matching contents? Even if the data could not be preserved in a portable format for later restoration, at least that would be something. -- Support extended attributes https://bugs.launchpad.net/bugs/112909 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 240063] Re: DNS servers disappear on restart
I can confirm this bug. I installed an 8.10 home server/gateway when it first came out, and it took me a while to even notice the bug because I run my own DNS server, but I now get reminded every time I try to 'dig' an address after a reboot. Given how critical a failure this can be for static IP users, I'm surprised this bug doesn't have a much higher priority. -- DNS servers disappear on restart https://bugs.launchpad.net/bugs/240063 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 61903] Re: dhcp3 fails to start during boot-time but starts seamlessly invoking the init-script manually
A VERY annoying bug indeed. About once every 1-3 weeks, I have to log into my server to start dhcp3-server when some desktop's lease expires and I realize it never got started or quit silently. I added '/etc/init.d/dhcp3-server restart' to my gateway setup script, but that drastically slows the execution of the script which is also responsible for manually resetting the PPPoE connection. -- dhcp3 fails to start during boot-time but starts seamlessly invoking the init-script manually https://bugs.launchpad.net/bugs/61903 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 389555] Re: [PATCH] ext4 filesystem corruption
Could someone please /finish/ the documentation in https://wiki.ubuntu.com/Testing/EnableProposed? The blurb in italics asking how to actually accomplish more than seeing a package list has been there for ages, and that's about as far as I can get as well. Aptitude does nothing because it erroneously believes that the newer version of linux-server is already installed, and I can't find any documentation that describes how to force aptitude to actually do something. Meanwhile, I've got a computing cluster that's regularly vomiting on its storage and threatening to sabotage 2 months of administrative work. Good thing I have backups... -- [PATCH] ext4 filesystem corruption https://bugs.launchpad.net/bugs/389555 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 112909] Re: Support extended attributes
SabreWolfy, I think you need to re-read this bug. It has nothing to do with the filesystem itself supporting extended attributes. Rather the problem is with all the user-land tools that do not, like cp, tar, graphical file managers, etc. Without these tools supporting them, filesystem support is useless in most situations. Of course, only Apple is stupid enough to design software that won't work without them and depends utterly on this metadata being preserved, which is why the issue does not arise more commonly. There wouldn't be that much need for the support otherwise. -- Support extended attributes https://bugs.launchpad.net/bugs/112909 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1737663] [NEW] dhclient fails setting default gateway to unreachable host
Public bug reported:
When receiving an IP from a DHCP server and a router IP that is not the
same IP, dhclient-script silently fails to add the router as a default
route for the interface (RTNETLINK answers: Network is unreachable).
Error occurs on line 320:
# set default route
ip -4 route add default via ${router} dev ${interface} \
${if_metric:+metric $if_metric} >/dev/null 2>&1
With no control over the DHCP server (an ISP-provided appliance
configured to propagate its external IP to this DHCP client), the
apparent solution (other than quick hard-coded hacks like `route add
default MYINTERFACE`) is to first create a single-ip route, adding the
preceding line:
ip -4 route add ${router} dev ${interface}
(Alternatively, collapsing the resulting two rules by replacing original
line's use of ${router} with ${new_ip_address} also works, and also
preserves the route table's resolution of the gateway ip to a hostname -
unlike the hack.)
I could probably write a more complex custom enter hook to correctly
handle the scenario, but this does not seem so terribly obscure to
justify it (standard appliance from a major Canadian ISP). With
sufficient information present to infer the correct routing, I believe
it should work out of the box.
I do not rule out consequences of doing so beyond my current grasp, and
it does seem odd to me that my ISP provides a gateway outside the
subnet. Nevertheless I hope some attention on the issue will yeild a
more robust stock configuration or at least some deeper insight.
(Sanitized) variable dump for dhclient-script:
Tue Dec 12 00:59:23 AST 2017: entering /etc/dhcp/dhclient-enter-hooks.d,
dumping variables.
reason='BOUND'
interface='eth0'
new_ip_address='123.45.114.112'
new_network_number='123.45.114.0'
new_subnet_mask='255.255.255.0'
new_broadcast_address='123.45.114.255'
new_routers='123.45.112.1'
new_domain_name='redacted.com'
new_domain_name_servers='127.0.0.1'
old_ip_address='123.45.114.112'
old_network_number='123.45.114.0'
old_subnet_mask='255.255.255.0'
old_broadcast_address='123.45.114.255'
old_routers='123.45.112.1'
old_domain_name='redacted.com'
old_domain_name_servers='127.0.0.1'
Routing rules with stock configuration (the only one that doesn't route
internet traffic):
Destination Gateway Genmask Flags Metric RefUse
Iface
123.45.114.0* 255.255.255.0 U 0 00 eth0
With my added line:
Destination Gateway Genmask Flags Metric RefUse
Iface
default fctnnbsc38w-123 0.0.0.0 UG0 00 eth0
fctnnbsc38w-123 * 255.255.255.255 UH0 00 eth0
123.45.114.0* 255.255.255.0 U 0 00 eth0
With interface ip as router ip:
Destination Gateway Genmask Flags Metric RefUse
Iface
default fctnnbsc38w-123 0.0.0.0 UG0 00 eth0
123.45.114.0* 255.255.255.0 U 0 00 eth0
With hardcoded hack:
Destination Gateway Genmask Flags Metric RefUse
Iface
default * 0.0.0.0 U 0 00 eth0
123.45.114.0* 255.255.255.0 U 0 00 eth0
** Affects: isc-dhcp (Ubuntu)
Importance: Undecided
Status: New
** Description changed:
When receiving an IP from a DHCP server and a router IP that is not the
same IP, dhclient-script silently fails to add the router as a default
route for the interface (RTNETLINK answers: Network is unreachable).
Error occurs on line 320:
- # set default route
- ip -4 route add default via ${router} dev ${interface} \
- ${if_metric:+metric $if_metric} >/dev/null 2>&1
+ # set default route
+ ip -4 route add default via ${router} dev ${interface} \
+ ${if_metric:+metric $if_metric} >/dev/null 2>&1
-
- With no control over the DHCP server (an IPS-provided appliance
+ With no control over the DHCP server (an ISP-provided appliance
configured to propagate its external IP to this DHCP client), the
apparent solution (other than quick hard-coded hacks like `route add
default MYINTERFACE`) is to first create a single-ip route, adding the
preceding line:
- ip -4 route add ${router} dev ${interface}
+ ip -4 route add ${router} dev ${interface}
(Alternatively, collapsing the resulting two rules by replacing original
line's use of ${router} with ${new_ip_address} also works, and also
preserves the route table's resolution of the gateway ip to a hostname -
unlike the hack.)
I could probably write a more complex custom enter hook to correctly
handle the scenario, but this does not seem so terribly obscure to
justify it (standard appliance from a major Canadian ISP). With
sufficient informatio
[Bug 1454725] Re: openvpn no longer called with "--script-security 2"
What about the originally reported issue? OPTARGS is still not supported. Or put another way, there are other flags some of us need to set (in my case --multihome). If not via OPTARGS, what is the proper way to set them? And why does /etc/default/openvpn still present OPTARGS as supported? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1454725 Title: openvpn no longer called with "--script-security 2" To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openvpn/+bug/1454725/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1191882] Re: PAM auth fails in client without server package
** Also affects: ubuntu Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1191882 Title: PAM auth fails in client without server package To manage notifications about this bug go to: https://bugs.launchpad.net/percona-server/+bug/1191882/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 576255] Re: can't install apache2.2-common (2.2.14-5ubuntu8)
Adam Conrad - "This isn't apache-specific, though it seems that apache users seem to be one of the larger groups of people who think that deleting conffiles will improve their lives somehow. Not really sure how to curb that, but not with bugs in apache." I didn't delete any config files, yet I also have this problem. And if apache upgrades break without faulty user intervertion, then it is most definitely a packaging bug. Locate reqtimeout returns only "/usr/lib/apache2/modules/mod_reqtimeout.so" but there has never been any matching set of .conf and .load files in /etc/apache2/mods- available, as verified by perusing full system backups dating back to 2010-07-31. The problem just occurred for me a couple weeks ago after no modification to the system--other than upgrades--since install at 2010-04-13. If I had to make a guess, it would be that dpkg is currently expecting a file that it didn't previously provide and then assuming its absence implicates manual deletion, which is obviously a problem for anyone who expects server upgrades between untampered states to be reliable. Shouldn't they? I'm not convinced that manual deletion should be allowed to interfere either. Non-stock configuration (particularly living in /etc) is sysadmin domain and none of dpkg's concern unless --purge --reinstall is explicitly requested. If user action has broken something, fine. Let user deal with it instead of taking down a service that might have been working anyway (as it was). All dpkg should be doing is reporting /changes/ in requirements, in which case it should be supplying them. -- can't install apache2.2-common (2.2.14-5ubuntu8) https://bugs.launchpad.net/bugs/576255 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 112909] Re: Support extended attributes
That may be fine for desktops, but where we were really devoid of options is on servers. The latest release (Ibex) in server edition now supports copying extended attributes with --preserve=all or the archive flag (-a). However it still failed when copying between two xattr- enabled partitions. I don't remember what finally worked. I did play with "star" a lot, which successfully made a backup of my data and restored it to another partition on the old install, but couldn't do the same on the new, using the same commands as before: Backup: star -c -dump path/to/backup > backup.star (Add -z to gzip output, -bz to bzip it.) Restore: star xvf backup.star target/restore/path -dump (Cannot directly restore compressed version.) Whatever finally worked, I had to spend an afternoon faffing about to accomplish it. Then I found out Ibex's calendarserver package is broken. /facepalm -- Support extended attributes https://bugs.launchpad.net/bugs/112909 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
