Re: [arch-general] [arch-dev-public] ppp 2.4.6 in testing breaks pptp connections in NetworkManager
În ziua de Duminică 23 Februarie 2014, la 10:39:36, Thomas Bächler a scris: Am 23.02.2014 08:42, schrieb Savyasachee Jha: Whenever I try connecting to my university's VPN, the authentication fails. Running systemctl status NetworkManager gives me the message: Feb 23 16:06:06 Empire NetworkManager[285]: info Starting VPN service 'pptp'... Feb 23 16:06:06 Empire NetworkManager[285]: info VPN service 'pptp' started (org.freedesktop.NetworkManager.pptp), PID 946 Feb 23 16:06:06 Empire NetworkManager[285]: info VPN service 'pptp' appeared; activating connections Feb 23 16:06:06 Empire NetworkManager[285]: info VPN plugin state changed: starting (3) Feb 23 16:06:06 Empire NetworkManager[285]: info VPN connection 'KUINS' (Connect) reply received. Feb 23 16:06:06 Empire pppd[947]: Plugin /usr/lib/pppd/2.4.5/nm-pptp-pppd-plugin.so is for pppd version 2.4.5, this is 2.4.6 Feb 23 16:06:06 Empire NetworkManager[285]: warn VPN plugin failed: 0 Feb 23 16:06:06 Empire NetworkManager[285]: info VPN plugin state changed: stopped (6) Feb 23 16:06:06 Empire NetworkManager[285]: info VPN plugin state change reason: 10 I went to /usr/lib/pppd and found 2 folders, 2.4.5 and 2.4.6. Should I recompile networkmanager-pptp and pptpclient? The networkmanager, networkmanager-pptp and pppd-ldap-simple packages should probably be recompiled. extra/networkmanager 0.9.8.8-1 /usr/lib/pppd/2.4.5/nm-pppd-plugin.so extra/networkmanager-pptp 0.9.8.4-1 /usr/lib/pppd/2.4.5/nm-pptp-pppd-plugin.so community/pppd-ldap-simple 0.12b-6 /usr/lib/pppd/2.4.5/pppd_ldap_simple.so (Good thing that anyone actually uses testing/ppp to notice these problems.) I've seen these issues but I didn't have enough time to come to a sane conclusion in order to report it. IIRC rp-pppoe in core has the same problem. pppd[27117]: Plugin /usr/lib/rp-pppoe/rp-pppoe.so is for pppd version 2.4.5, this is 2.4.6 Bug report at: https://bugs.archlinux.org/task/39007 -- Arthur Țițeică signature.asc Description: This is a digitally signed message part.
Re: [arch-general] libreoffice-writer upgrade
Hi În ziua de Duminică 23 Februarie 2014, la 19:56:16, Myra Nelson a scris: /usr/lib/libreoffice/program/soffice.bin: error while loading shared libraries: libtubeslo.so: cannot open shared object file: No such file or directory That file is in libreoffice-calc # pkgfile libtubeslo.so testing/libreoffice-calc -- Arthur Țițeică signature.asc Description: This is a digitally signed message part.
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
În ziua de Miercuri 26 Martie 2014, la 19:56:26, Thomas Bächler a scris: I want to trim our kernel down to what we actually support. 1) Once we agreed to disable one LSM, everyone else said we can enable LSM XYZ, too. And so we did. Right now, we enable SELinux, SMACK, Tomoyo, AppArmor and Yama, although we don't support the userspace for any of those. My opinion on this is that the kernel should be the ground on which userspace should always work. Features should be taken out with bug reports demonstrating breakage in general usage, slowdowns or security risks. Another important point of view should be the maintenance required to support these seldom used features and I have nothing to comment on this. Specifically regarding slowdowns, my layman opinion on this is that they are meaningless in the general usage of the -ARCH kernel. If taking out theoretically useful features out of the kernel means that in the end we gain 2 Mb of free memory or Apache is able to sustain 10500 connections instead of 1 I personally don't see it as good bargain. Building a personal or an AUR linux package is easy. Maintaining one is a lot harder. The most important thing that is lost in this process is the community support. One cannot compare the scrutiny and the testing of any AUR linux package with those of the -ARCH kernel. That being said I'd like to read and help test a before and after kernel in regards to performance or any other concerning factor. -- Arthur Țițeică signature.asc Description: This is a digitally signed message part.
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
Hi, În ziua de Joi 27 Martie 2014, la 23:49:45, Thomas Bächler a scris: And here is my problem: Audit is enabled by default and must be explicitly disabled by the admin. This is a showstopper for me! There is no kernel option to configure audit to be disabled by default (as far as I am aware) so that it can be enabled with 'audit=1' on the command line. I couldn't find a definitive answer but the two documents I did find ¹² suggest that having selinux and audit fully functional (not just enabled) has no real performance impact. Kernel debugging options on the other side seem to have a much bigger impact. It raises a question mark that the two most important components of a system (systemd and the kernel) have security measures disabled. People in this thread like to put out the over subjective lightweight factor but still there are no bug reports or any other solid evidence that the kernel ate their computers since apparmor, selinux and audit were semi-silently enabled a few builds back. The facts will remain though: * the kernel will still be everything and the kitchen sink. * no provable performance enhancement so far. * security measures will get back at square 1. ¹ http://www.phoronix.com/scan.php?page=articleitem=fedora_debug_selinux ² https://dl.dropboxusercontent.com/u/29107946/Assessing-the-Performance-Impact-of-the-Linux-Kernel-Audit-Trail.pdf As a side note I will try to test the worst case scenario in the Phoronix tests -- Postmark, and post the results here. -- Arthur Țițeică signature.asc Description: This is a digitally signed message part.
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
Hi, În ziua de Vineri 28 Martie 2014, la 12:54:44, Arthur Țițeică a scris: As a side note I will try to test the worst case scenario in the Phoronix tests -- Postmark, and post the results here. I managed to finish testing. As said above I picked up this test because it was the only one standing out with a great difference between the stock kernel and a selinux/audit configured kernel. It's also a very easy test to perform. The raw spreadsheet data and the conditions for the test may be found at ¹. I would really appreciate some help creating some nice graphs with this data. My conclusions so far: there's no difference between the stock -ARCH kernel and my -NOLSM build in which I disabled all LSMs (and hence audit). Note: the final test with 50 files for the rotational disk isn't finished yet because... really... I shaved twice during the HDD tests. A side note regarding these tests: SSDs act according to their fame and HDDs are as misleading as a daily horoscope. I do plan to also test a no-debug but LSM enabled kernel even if it's just for the sake of statistics. ¹ https://dl.dropboxusercontent.com/u/29107946/linux-lsm/postmark-test.ods -- Arthur Țițeică signature.asc Description: This is a digitally signed message part.
