Re: [arch-general] How to reboot remotely without hanging ssh session?
On Wed, 05 Feb 2014 13:19:56 -0600 "David C. Rankin" wrote: > Guys, > >I remote administer one arch server and after moving to systemd I haven't > found a way to reboot without hanging the ssh session. Prior to system, we > could simply pass the shutdown command via ssh and the ssh session would > complete/close before reboot took place: i.e. > > $ ssh remote.host.org "sudo shutdown -r now" > >However with systemd, using "systemctl reboot" the ssh session hangs > until the remote host reboot or a timeout occurs. > >Is there a better way to reboot a remote server and avoid this? > AFAIU, this issue is related to the lack of ordering between systemd-user-sessions.service and network.target (the former should start after the latter)... OTOH, one can simply $ ssh r...@remote.host.org and do # ( sleep 30 && systemctl reboot ) & # exit Cheers, -- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature
Re: [arch-general] Linux container
On Wed, 12 Feb 2014 12:59:43 +0100 arnaud gaboury wrote: > Dear all, > > I am slowly building a Arch Linux VM guest on my Arch Linux host. > > The guest machine is now built and is recognized as shown by this command : > > gabx@hortensia ➤➤ ~ % machinectl list > MACHINE CONTAINER SERVICE > dahlia container nspawn > > 1 machines listed. > > I an following the libvirt.org documentation. Now, according this > page[1] about lxc driver, i am dealing with namespace requirements. > This sentence, in bold, puzzles me: > > A suitably configured UID/GID mapping is a pre-requisite to making > containers secure, in the absence of sVirt confinement. > > If I understand what a namespace is, I have no idea how to make sure > my UIG/GID mapping is well configured. I would appreciate having any > hints abut this part of the settings. User namespaces are currently disabled in the -ARCH kernel, so you should either build your own kernel, or do not configure any mapping (it is optional). > > Another question : is there any advantage/disadvantage using the lxc > Userspace tools[2] instead of libvirt to manage these namespaces ? Namespaces are property of the kernel, not a userspace tool, so both are equivalent. Having said that, I prefer lxc tools because they are somewhat more flexible and come with fewer dependencies. Also notice, that if you don't need an advanced network configuration, systemd-nspawn may be sufficient for your purposes. > > Thank you for help. > > > > > [1]http://libvirt.org/drvlxc.html > [2]http://linuxcontainers.org/ -- Leonid Isaev GPG key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature
Re: [arch-general] Linux container
On Thu, 13 Feb 2014 19:00:49 +0100 arnaud gaboury wrote: > > > > This feature is relatively new and is not enabled in the default Arch > > Linux kernel: > > $ zgrep USER_NS /proc/config.gz > > # CONFIG_USER_NS is not set > > > > You'll have to build a custom kernel. > > > > -- > > Timothée Ravier > > now I rebuilt the kernel with user space set. > Shall I do another new install for the container with this new kernel? > Or keep the container installed with the "old" kernel? Probably not. The only thing you need to change is config, but you'd better check libvirt docs. By the way, there was a reason why usens was disabled in our kernel (FS#36969)... Cheers, -- Leonid Isaev GPG key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature
[arch-general] Updating the archlinux-keyring package
Hi, Recently I had to fix a corrupted pacman db from a 3 month old livecd and realized that this process is not so innocent. Specifically, there is a chance to get a trojaned package on the system simply because the archlinux-keyring package on the iso is outdated. Of course, other similar scenarios are possible, e.g. a fresh install is made from an old livecd, or a server is updated after several months of uptime: new packages are pulled in but signature checks are made using the old keyring currently on the host. So, instead of relying on the discrete updates of archlinux-keyring, wouldn't is make more sense to have a systemd timer/cron job to frequently refresh pacman keyring? Thanks, -- Leonid Isaev GPG key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature
Re: [arch-general] Updating the archlinux-keyring package
On Fri, 14 Feb 2014 03:43:38 -0800 Don deJuan wrote: > On 02/14/2014 03:00 AM, Plonky Duby wrote: > > I do agree with that, i switched on a laptop which was off since september > > 2013 and i had some issue with some key. > > > > I had to update key, before having a sucessfull update. > > > > > > > > > > 2014-02-13 20:21 GMT+01:00 Leonid Isaev : > > > >> Hi, > >> > >> Recently I had to fix a corrupted pacman db from a 3 month old > >> livecd > >> and realized that this process is not so innocent. Specifically, there is > >> a chance to get a trojaned package on the system simply because the > >> archlinux-keyring package on the iso is outdated. Of course, other similar > >> scenarios are possible, e.g. a fresh install is made from an old livecd, > >> or a > >> server is updated after several months of uptime: new packages are pulled > >> in > >> but signature checks are made using the old keyring currently on the host. > >> So, instead of relying on the discrete updates of > >> archlinux-keyring, > >> wouldn't is make more sense to have a systemd timer/cron job to frequently > >> refresh pacman keyring? > >> > >> Thanks, > >> -- > >> Leonid Isaev > >> GPG key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D > >> > > pacman-key --refresh-keys ?? Well, I run this on the home server via a systemd timer, so that I don't forget to do it before an update. It is certainly not necessary on a frequently updated machine, but might be a good idea for a livecd before an installation. Cheers, -- Leonid Isaev GPG key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature
Re: [arch-general] libvirt / lxc : no valid cgroup for machine
On Sat, 15 Feb 2014 21:04:43 +0100 arnaud gaboury wrote: > > Thank you Tom for your long and precise help. I think I will give up > > libvirt and go to LXC. Btw, the container does not need so much > > settings offer by libvirt management. > > For your info, /etc/cgconfig is needed and read by systemd > > cgconfig.service. But there is no need in fact to enable this service. > > > I gave a try to LXC. There is unfortunately no better doc, and it > seems I still have an issue with my cgroup configuration: What LXC version do you use? Cheers, -- Leonid Isaev GPG key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature
Re: [arch-general] [arch-dev-public] systemd 209 in [testing]
On Fri, 21 Feb 2014 10:24:39 +0100 Thomas Bächler wrote: > Am 20.02.2014 17:33, schrieb Dave Reisner: > > Hi all, > > > > I'm working on packaging the systemd 209 release, and I expect to have > > pkgrel=1 into [testing] in a few hours, barring any unforseen problems. > > It's a huge release (nearly 2000 commits since 208), and I don't > > anticipate that this will make it into [core]. > > This version works fine on my desktop, but fails on my laptop. The > initramfs works fine. While booting up the system, systemd hangs and > this appears in the journal: > > systemd[1]: Assertion '(x->type == SOURCE_MONOTONIC && y->type == > SOURCE_MONOTONIC) || (x->type == SOURCE_REALTIME && y->type == > SOURCE_REALTIME)' failed at src/libsystemd/sd-event/sd-event.c:264, > function latest_time_prioq_compare(). Aborting. > systemd[1]: Caught , dumped core as pid 317. > > As long this is turning into a thread about newly introduced issues in systemd... Udev 209 now tries to rename (I guess) all interfaces, including virtual: $ journalctl -u systemd-udevd.service PRIORITY=3 -o cat Could not apply link config to br0 Could not apply link config to vethQEP978 Could not apply link config to vethDR7OA5 Could not apply link config to vethW1QM0I Could not apply link config to vethC4240S Those are bridge and veth interfaces created by lxc userspace tools (2 containers/2 ifaces per container). Is this intended? Thanks, -- Leonid Isaev GPG key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature
Re: [arch-general] Bridge interface with netctl
On Tue, 25 Feb 2014 12:47:02 +0100 arnaud gaboury wrote: > Dear list, > > I am messing with assigning a static IP on a systemd-nspawn container, > on both sides (host,container). You assign an IP address only inside the container. > My idea is to first create a bridge (br0) on the host. > [...] > gabx@hortensia ➤➤ ~ % cat /etc/netctl/bridge-hortensia > Description="Example Bridge connection" > Interface=br0 > Connection=bridge > BindsToInterfaces=enp7s0 > IP=no This profile is wrong. Here is the right one: --- $ cat /etc/netctl/lxc_lan_bridge Description="LAN bridge for LXC containers" Connection=bridge Interface=br0 SkipNoCarrier="yes" BindsToInterfaces=() IP=static Address=(10.137.0.1/24) --- Also, since you are running systemd >= 209, you can use networkd. Here are the config files: --- $ cat /etc/systemd/network/lxc_bridge.netdev [NetDev] Name=br0 Kind=bridge $ cat /etc/systemd/network/lxc_bridge.network [Match] Name=br0 [Network] Description=LAN bridge for LXC containers DHCP=false [Address] Address=10.137.0.1/24 --- Now: * Populate the iptables FORWARD chain to route traffic from your physical interface to the bridge and back. * Inside the container, get rid of dhcpcd, and use either networkd or netctl to assign a static IP like you would do on a physical host. * The simplest way to take care of DNS (that is without any additional host configuration) is to use a static resolv.conf inside the container with a public DNS service, e.g. --- $ cat /var/lib/lxc/appserver1/rootfs/etc/resolv.conf nameserver 8.8.8.8 nameserver 8.8.4.4 --- Cheers, -- Leonid Isaev GPG key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature
Re: [arch-general] Any way to change .PKGINFO post build w/o Rebuilding?
On Wed, 26 Feb 2014 15:06:36 -0600 "David C. Rankin" wrote: > On 02/26/2014 05:45 AM, Gesh wrote: > > A naïve reading of [1] suggests that makepkg -R should do the trick. > > However, as I'm away from my computer, I can't test > > this. > > Gesh > > [1] - https://www.archlinux.org/pacman/makepkg.8.html > > With just about every other package, that is OK, but not in the case of > tdebase. There are files autogenerated during Make and copied to 'pkg' that > are not present if makepkg -R is called (makepkg wipes out 'pkg' before > repackaging -- so in this case it will not work). That is what prompted this > manual question. Thanks though. Why is this a problem? If you have a build directory in src/, then autogenerated files are there, so makepkg -R will reexec package() which will copy those files again. If make(1) copies those files directly, i.e. not being instructed by the PKGBUILD, then your package is broken. Cheers, -- Leonid Isaev GPG key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature
Re: [arch-general] netctl provides wifi-menu which is unusable
On Thu, 27 Feb 2014 18:10:39 +0100 Nowaker wrote: > Guys, the goal of this "slanted ranting" (really?) is to propose a good > solution and make Arch better. Please think out of the box and answer > one question: > > Would a separate netctl-wifi-menu package that depends on dialog, > wpa_supplicant and dhcpcd be better or not - and why? No, it won't. Because the metadata will take more space than the actual application. Besides, wpa_supplicant and dhcpcd is needed not only for wifi-menu. > > My answer is yes: it will make wifi-menu usable to anyone who wants to > use wifi-menu and installs the package. IMHO, wifi-menu has always been a strange tool because it requires root privileges to operate. But if I login as root, I might as well use wpa_cli, iw or write a profile directly. It would be nice if we could use polkit for non-root users... Cheers, -- Leonid Isaev GPG key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature
Re: [arch-general] netctl hangs after last update
On Mon, 10 Mar 2014 19:54:56 +0100
Robert Knauer wrote:
> Hello,
> after the update yesterday (see pacman log at the end of the e-mail),
> netctl hangs when I try to start my network connection with the error
> message:
> > A dependency job for netctl@conn1.service failed. See 'journalctl
> > -xn' for details.
> The hanging sub-process of netctl seems to be
> /usr/bin/systemd-tty-ask-password-agent --watch.
AFAIK, netctl doesn't call this.
>
> In my syslog are the following lines:
> > [19:42:09] info daemon systemd Expecting device sys-subsystem-
> > net-devices-eth0.device...
> > [19:43:39] warning daemon systemd Job sys-subsystem-net-devices-
> > eth0.device/start timed out.
> > [19:43:39] err daemon systemd Timed out waiting for device
> > sys-subsystem-net-devices-eth0.device.
> > [19:43:39] err daemon systemd Dependency failed for The main network
> > connection.
So, what exactly is your question?
Systemd looks and doesn't find eth0, which is correct since your interface is
ens3. In your /etc/systemd/system there should be a .service file which netctl
created when you enabled the profile. I bet that unit is the culprit.
>
> My netctl profile is the following:
> > Description='The main network connection'
> > Interface=ens3
> > Connection=ethernet
> > IP=static
> > Address=('xx.xx.xx.xx/22')
> > Gateway='xx.xx.xx.xx'
> > DNS=('xx.xx.xx.xx' 'xx.xx.xx.xx')
> > IP6=static
> > Address6=(':::::1/64')
> > Gateway6='fe80::1'
>
> My network interfaces:
> # ifconfig -a
> ens3: flags=4163 mtu 1500
> inet xx.xx.xx.xx netmask 255.255.252.0 broadcast xx.xx.xx.xx
Just FYI, hiding IP and MAC addresses is kinda silly...
Cheers,
--
Leonid Isaev
GPG key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
signature.asc
Description: PGP signature
Re: [arch-general] [arch-dev-public] Cyclic dependencies between systemd and util-linux
On Wed, 12 Mar 2014 17:21:20 +0100
Tobias Powalowski wrote:
> Am 12.03.2014 06:32, schrieb Gerardo Exequiel Pozzi:
> > On 02/24/2014 03:56 PM, Thomas Bächler wrote:
> >> Right now, we have a problem with cyclic dependencies in core: systemd
> >> requires libblkid and libuuid (systemd-udevd) and util-linux requires
> >> libudev (findmnt, and soon uuidd [1]).
> >>
> >> I don't like this situation and currently it is revoled by adding
> >> systemd as optdepend to util-linux. This has the side effect that in a
> >> chroot with only certain packages installed, one has to explicitly
> >> install systemd to get findmnt working. Since I've run into this
> >> situation and cyclic deps are bad, I propose the following:
> >>
> >> Split both util-linux and systemd into libutil-linux/util-linux and
> >> libsystemd/systemd. Then we could have both util-linux and systemd
> >> depend on both libsystemd and libutil-linux.
> >>
> >> [1] http://www.spinics.net/lists/util-linux-ng/msg08699.html
> >>
> > We also have another set when installing {base} group:
> >
> > warning: util-linux will be installed before its coreutils dependency
> > warning: util-linux will be installed before its pam dependency
> > warning: shadow will be installed before its pam dependency
> >
> >
> New depends introduce error during base installation,
> libutil-linux needs coreutils first else no install is found.
Sorry for cross-list posting...
Actually, this is an old error which I saw on all new installs for quite some
time. For example:
-
[2014-02-14 19:46] [PACMAN] installed shadow (4.1.5.1-7)
[2014-02-14 19:46] [ALPM-SCRIPTLET] /tmp/alpm_p51CHp/.INSTALL: line 6:
install: command not found
[2014-02-14 19:46] [PACMAN] installed util-linux (2.24.1-1)
-
Cheers,
L.
--
Leonid Isaev
GPG key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
signature.asc
Description: PGP signature
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
On Wed, 26 Mar 2014 19:56:26 +0100 Thomas Bächler wrote: > Hello all, > > it won't be too long until 3.14 is out and I want to address a topic > that has been bugging me for a while. Our kernel includes everything and > the kitchensink. I have no problem with delivering drivers that can be > built modular, but there are other things that have an unknown impact on > everyone. > > I want to trim our kernel down to what we actually support. Thanks for doing this. > > 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. > > I propose to drop all of them. I agree regarding SELinux/Apparmor (it's not only userspace tools, but also sane application policies that are missing). However, I don't think that Yama requires any userspace components, does it? Currently, I boot with "security=yama" and completely disabled non-admin ptrace (kernel.yama.ptrace_scope=2). Perhaps -ARCH kernels should keep Yama available albeit disabled by default (as they now do). > > 2) We patch our kernel to allow enabling CHECKPOINT_RESTORE without > enabling CONFIG_EXPERT. I have no idea what the impact of this option > is, other than that it was requested in order to support some tool that > can freeze and save single processes resume them later. I am generally > sceptical towards options that require CONFIG_EXPERT, so I propose > dropping this one, too. > > 3) We enable tons of debug options in the "Kernel Hacking" section, many > of which have a "small performance impact". I'd like to get rid of those > that we don't need (I didn't go through all of them yet). > > What I'd like is a discussion where people suggest more things that > could or should be dropped, and tell me what is absolutely needed and > why. I hope that such a discussion makes it clearer to me how I should > proceed. > > Regards > Thomas > Best, -- Leonid Isaev GnuPG key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
On Wed, 26 Mar 2014 21:00:15 +0100 Thomas Bächler wrote: > Am 26.03.2014 20:18, schrieb Leonid Isaev: > > However, I don't think that Yama requires any userspace components, does > > it? Currently, I boot with "security=yama" and completely disabled > > non-admin ptrace (kernel.yama.ptrace_scope=2). Perhaps -ARCH kernels > > should keep Yama available albeit disabled by default (as they now do). > > Once yama is built-in, the ptrace_scope protection is enabled by > default. There is no option to change that. > But by default, kernel.yama.ptrace_scope = 0, which according to documentation (Yama.txt) is like having no ptrace restriction at all, and indeed gdb/strace work... Best, -- Leonid Isaev GnuPG key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
On Wed, 26 Mar 2014 22:17:25 +0100 Thomas Bächler wrote: > Am 26.03.2014 21:31, schrieb Leonid Isaev: > > On Wed, 26 Mar 2014 21:00:15 +0100 > > Thomas Bächler wrote: > > > >> Am 26.03.2014 20:18, schrieb Leonid Isaev: > >>> However, I don't think that Yama requires any userspace components, does > >>> it? Currently, I boot with "security=yama" and completely disabled > >>> non-admin ptrace (kernel.yama.ptrace_scope=2). Perhaps -ARCH kernels > >>> should keep Yama available albeit disabled by default (as they now do). > >> > >> Once yama is built-in, the ptrace_scope protection is enabled by > >> default. There is no option to change that. > >> > > > > But by default, kernel.yama.ptrace_scope = 0 > > No. The default is 1. > Yes, you are right, I was speaking from the old memory... If this causes problems and a default sysctl.d/ conf file is not desired, then I guess, Yama can go away as well. Does this discussion also apply to the -lts kernel? Thanks, -- Leonid Isaev GnuPG key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature
Re: [arch-general] pacman-key complaining, but what to do about it?
On Wed, 02 Apr 2014 18:47:52 +0200 Nowaker wrote: > > There may be a transparent proxy in your routing chain that strips > > compression in order to run a virus scan. > > Time for SSL-securing Arch Linux repos to prevent any sort of > man-in-the-middle attacks? Even such trivial things like compression > stripping, or image optimization often performed by mobile internet > providers is a man-in-the-middle. This should be fought by any means. > If you are talking about mirrors, then look at https://www.archlinux.org/mirrorlist/all/https/ . At least in my experience, using tls allows to evade certain routers which redirect to a captive portal if plain http is used, but don't touch encrypted traffic (e.g. if you are in a hotel and need to install something). However, tls adds CPU overhead and is not a way to fight broken ISPs and proxies/routers. Cheers, -- Leonid Isaev GnuPG key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature
[arch-general] Using timers instead of cron jobs
Hi, On a current [testing] installation, there are several timer symlinks in /usr/lib/systemd/system/multi-user.target.wants (shipped with logrotate, man-db, etc.). What is the reason for choosing multi-user.target instead of timers.target? Thanks, -- Leonid Isaev GnuPG key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature
Re: [arch-general] Heartbleed-bug in OpenSSL 1.0.1 up to 1.0.1f
[ I had to reconstruct the message from the online archive -- sorry if message ID is screwed ] On Tue, 8 Apr 2014 17:54:14 +0100 adys.wh at gmail.com (Jerome Leclanche) wrote: > Slightly OT but for those interested, I added the heartbleed utility > (used by the heartbleed checker site) to the AUR: > https://aur.archlinux.org/packages/heartbleed-git/ > > % heartbleed mediacru.sh:443 > 2014/04/08 17:53:57 mediacru.sh:443 - SAFE > J. Leclanche One should probably make clear that openssh servers/clients are _not_ affected because ssh does not use TLS: http://serverfault.com/questions/587433/heartbleed-are-services-other-than-https-affected . -- Leonid Isaev GPG key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature
[arch-general] On-boot delay due to timer units
Hi, Since anacron jobs were replaced with timers, I am seeing a noticeable delay before agetty prompt appears on machines which were unused for some time (due to update/man-db timers starting up simultaneously). TLDR: Anacron inserts a random delay between boot and running the jobs, so is it possible to simulate this behavior by including e.g. "OnBootSec=..." in the timers at next update? Or is this option incompatible with OnCalendar? Here is the (edited) "statistics" obtained by grepping /var/log/daemon.log. The disk is actually an Intel X-25 (sata-2) SSD. --- No timers are active (baseline) --- Apr 6: 5.983s (kernel) + 1.947s (userspace) = 7.930s. Apr 6: 5.815s (kernel) + 2.494s (userspace) = 8.310s. Apr 6: 5.692s (kernel) + 1.612s (userspace) = 7.304s. Apr 7: 5.874s (kernel) + 2.561s (userspace) = 8.436s. Apr 9: 5.704s (kernel) + 3.001s (userspace) = 8.706s. Apr 10: 5.612s (kernel) + 2.494s (userspace) = 8.106s. Apr 11: 5.618s (kernel) + 2.908s (userspace) = 8.526s. Apr 12: 5.671s (kernel) + 3.345s (userspace) = 9.016s. --- Timers first run --- Apr 14: 5.464s (kernel) + 46.883s (userspace) = 52.348s. --- Startup with timers --- Apr 15: 5.715s (kernel) + 2.878s (userspace) = 8.593s. Apr 16: Not powered on Apr 17: 6.414s (kernel) + 7.785s (userspace) = 14.200s. $ systemd-analyze blame | head 6.724s man-db.service 1.935s updatedb.service 926ms root-ssh-key-init@0x14d33aba.service 507ms lxc@appserver\x2dx86_64.service 427ms rfkill-unblock@wlan.service 381ms systemd-networkd.service 340ms wlan-powersave@wls1.service 289ms syslog-ng.service 235ms volatile-mail.service 225ms iptables.service Thanks, L. -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature
Re: [arch-general] On-boot delay due to timer units
On Thu, 17 Apr 2014 21:31:07 +0200 Thomas Bächler wrote: > Am 17.04.2014 20:56, schrieb Leonid Isaev: > > Hi, > > > > Since anacron jobs were replaced with timers, I am seeing a noticeable > > delay before agetty prompt appears on machines which were unused for some > > time (due to update/man-db timers starting up simultaneously). > > > > TLDR: Anacron inserts a random delay between boot and running the jobs, so > > is it possible to simulate this behavior by including e.g. "OnBootSec=..." > > in the timers at next update? Or is this option incompatible with > > OnCalendar? > > OnBootSec would cause the timers to always run on boot, no matter how > much time has passed, which is not what we want. OK. > > I don't think it is a problem that the timers run on boot, but rather > that they delay Type=idle units, like agetty. From what the > documentation says, there should not be any delay: > > "Behavior of idle is very similar to simple; however, actual execution > of the service binary is delayed until all jobs are dispatched." > > I am confused why get a delay here. I think the problem is the disk I/O generated due to e.g. man-db indexing, because I see the hdd light is solid on. So, my guess is that two things can happen: either the login prompt is delayed, or the prompt is shown but the actual login will stall. > > I think another solution in systemd would be introducing a holdoff time: > Instead of running immediately on boot, the timer should be scheduled > for boot+5min. You are right -- that's the best way to put it. Except, I'd generate random timeouts (distributed in some interval) for the corresponding services... Thanks, L. -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature
Re: [arch-general] On-boot delay due to timer units
On Thu, 17 Apr 2014 21:31:07 +0200 Thomas Bächler wrote: > [...] > > I think another solution in systemd would be introducing a holdoff time: > Instead of running immediately on boot, the timer should be scheduled > for boot+5min. > > This requires some investigation - sorry, I don't have a quick solution > right now. > AFAIU, there are 2 real issues here: 1. We hook to the boot process a bunch of disk-intensive operations which did not belong there in the 1st place. 2. Even if a boot delay for timers is implemented or the behavior of Type=idle units is "fixed" somehow in systemd, still all "cron" timers will be started in parallel which may result in a slow/unresponsive system. Note, that under anacron they were serialized by run-parts. BTW, thanks for bringing this up on systemd ML. L. -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature
Re: [arch-general] Comment on: Use systemd timers instead of /etc/cron.{hourly, daily, weekly, monthly}?
On Fri, 25 Apr 2014 17:19:04 -0400
Carl Schaefer wrote:
> It seems to me that, compared to cron/anacron, systemd timers currently
> offer reduced functionality and no clear benefit (I don't consider the
> act of uninstalling cron to have significant value in itself).
But then again, you don't maintain the cron package...
> Losing
> the ability to control when jobs run is giving up a lot; without that,
> the more use is made of systemd timers, the more unpredictable the
> results will be.
See systemd.timer(5) manpage. The timer configuration _should be_ one-to-one
equivalent to a crontab, except for a different syntax...
>
> Perhaps I'm missing something, because I don't fully understand all the
> points Thomas raised last month in his proposal on arch-dev-public:
>
> > Pros:
> > * enabled by default (in contrast to cronie)
> > * systems without need for crontabs can disable/uninstall cron
> > * service will be simpler than the rather long dropin scripts
> >
> > Cons:
> > * services are run in parallel instead of sequentially (is this even a
> > con? timer start will be randomized, and we can increase accuracy to an
> > hour to randomize even more)
> > * no holdoff time after boot as it seems
>
> pro#3 is a mystery to me,
Just compare {man-db,logrotate,updatedb}.service files with the corresponding
scripts in cron.daily...
> and missing from the "con" list is the point
> Maciej raised about the effect random timer jobs can have on busy
> servers.
So far, I have seen only (minor) inconveniences associated with switching to
the timers, which essentially have to do with system(d) startup time. Notice
that these issues will not be visible on servers because there systemd's
parallellization of the boot process is irrelevant.
The timer jobs are niced to 19 so if the server is busy they should wait, no?
>
> If this ship is already sailing, though, the goal should be to add
> functionality to systemd timers so that it becomes a real replacement
> for cron, e.g. allow execution windows to be defined, jobs placed within
> these windows, and scheduling parameters like acceptable degrees of
> parallelism to be specified. Something like that could be more powerful
> and flexible than cron, and potentially easier to manage than a set of
> crontabs. Does anyone know if the systemd timers roadmap includes
> anything like this?
Ask this on [systemd-devel].
Cheers,
L.
--
Leonid Isaev
GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4
C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
signature.asc
Description: PGP signature
Re: [arch-general] netctl/systemd - permission error in dmesg - need fixing?
On Fri, 02 May 2014 09:52:38 -0500 "David C. Rankin" wrote: > All, > > Checking dmesg, I found the line: > > [2.865094] systemd[1]: Configuration file > /etc/systemd/system/netctl@rlf_network\x2dstatic.service is marked > world-inaccessible. This has no effect as configuration data is accessible > via APIs without restrictions. Proceeding anyway. See http://lists.freedesktop.org/archives/systemd-devel/2014-February/017146.html : * When reading unit files, systemd will now verify the access mode of these files, and warn about certain suspicious combinations. This has been added to make it easier to track down packaging bugs where unit files are marked executable or world-writable. Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature
Re: [arch-general] Comment on: Use systemd timers instead of /etc/cron.{hourly, daily, weekly, monthly}?
Hi, On Mon, 5 May 2014 08:05:08 -0500 Maciej Puzio wrote: > I have been testing the issue for a week. Daily timers are fired > between 0:00 and 0:01 without exception - all timers at the same time, > all machines at the same time, every day at the same time. The largest > variation I have seen was 30 seconds. So yes, there is definitely an > issue with AccuracySec=12h not being honored. AFAIU systemd is supposed to start timers "randomly" in the time interval [1d, 1d + 12h]; different timers are started in parallel. Are you arguing that the starting time is not "random" enough? > > However, whether timer accuracy is 30 seconds or 12 hours, this makes > little difference to me, as both are unacceptable without the > possibility to customize timer elapse time. I have reverted all my > Arch machines to previous cron-based config and intend to keep it this > way. Perhaps it is not "cool", but at least it works. You misunderstood the point here. Systemd timers (at least in the current form) are _not_ cron replacement. However, they are adequate for daily maintainance jobs that are shipped with packages. If you had custom, carefully scheduled cron jobs, you should continue using cronie. What I don't understand is why do you care when man-db/updatedb runs? > > An example of such a solution > would be hourly/daily/monthly/weekly timers that execute scripts from > relevant /etc/cron.* directories. That would allow for removal of > cronie while sidestepping timer elapse problems that we are discussing > here. It would also have a benefit of handling all cron tasks in > addition to logrotate/updatedb/man-db/shadow. The scripts mainly set up the environment which is now done by systemd. You issue is with scheduling, and it will _not_ go away because scripts are still executed by systemd (as opposed to cronie). Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature
Re: [arch-general] Comment on: Use systemd timers instead of /etc/cron.{hourly, daily, weekly, monthly}?
On Tue, 6 May 2014 13:23:26 -0500 Maciej Puzio wrote: > As I wrote before, I can edit every timer file and set the elapse > time. What I can't do is to change one setting which says when daily > maintenance tasks are run. This was possible with cron, but is no > longer possible now. What's the problem to edit four files? Well, this > is multiplied by the number of machines that are under my care. > Again, here is relevant systemd RFE link: > https://bugs.freedesktop.org/show_bug.cgi?id=77938 This is bogus. See "man 7 systemd.time"; what you want is something like "OnCalendar=*-*-* 04:10:20" for a job that runs every day at 4:10:20 AM. > On Mon, May 5, 2014 at 12:21 PM, Leonid Isaev wrote: > > Systemd timers (at least in the current form) are _not_ cron replacement. > > However, they are adequate for daily maintainance jobs that are shipped > > with packages. If you had custom, carefully scheduled cron jobs, you should > > continue using cronie. What I don't understand is why do you care when > > man-db/updatedb runs? After re-reading the documentation I have to take this back, systemd timers seem to implement all features provided by cronie. Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature
Re: [arch-general] Comment on: Use systemd timers instead of /etc/cron.{hourly, daily, weekly, monthly}?
Hi, On Wed, 7 May 2014 13:34:29 -0500 Maciej Puzio wrote: > On Tue, May 6, 2014 at 3:13 PM, Leonid Isaev wrote: > > On Tue, 6 May 2014 13:23:26 -0500 > > Maciej Puzio wrote: > > > >> As I wrote before, I can edit every timer file and set the elapse > >> time. What I can't do is to change one setting which says when daily > >> maintenance tasks are run. This was possible with cron, but is no You mean, you could change /etc/anacrontab? > >> longer possible now. What's the problem to edit four files? Well, this > >> is multiplied by the number of machines that are under my care. Why can't you put additional configs in /etc/systemd/system/xxx.timer.d/ dir? > >> Again, here is relevant systemd RFE link: > >> https://bugs.freedesktop.org/show_bug.cgi?id=77938 > > > > This is bogus. > > Leonid, please reread the above paragraph and my previous posts, with > comprehension. With all due respect, your replies are not related to > the issue discussed. It is completely unclear what you want to be fixed and the title is misleading... If you have machines m_1 ... m_N and want to spread the anacron jobs, you need to edit N anacrontabs, right? Now you need to do k*N changes, k -- the number of jobs used to be started by anacron. Are you asking for a centralized control affecting all "daily" timers like the per-machine anacrontab? If true, this is unlikely to be implemented (at least I wouldn't do it). Perhaps a proper approach is to create a special target for your maintainance jobs which would pull all relevant services and would itself be triggered by an OnCalendar timer. Although I am not sure whether a timer can directly trigger a target yet... Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature
Re: [arch-general] Comment on: Use systemd timers instead of /etc/cron.{hourly, daily, weekly, monthly}?
On Thu, 8 May 2014 14:24:45 +0900 Savyasachee Jha wrote: > On Thu, May 8, 2014 at 6:23 AM, Leonid Isaev wrote: > > > > > Perhaps a proper approach is to create a special target for your > > maintainance > > jobs which would pull all relevant services and would itself be triggered > > by an > > OnCalendar timer. Although I am not sure whether a timer can directly > > trigger > > a target yet... > > > > > They can, do refer to > https://wiki.archlinux.org/index.php/Systemd/cron_functionality where you > can find some examples of the same. > Cool. I didn't know about that wikipage. Thanks, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature
Re: [arch-general] How to disable systemd-tmpfiles-clean.timer
Hi, On Thu, 08 May 2014 02:43:57 -0400 Olivier Langlois wrote: > Since a recent update (I have first noticed a couple of weeks ago this > new systemd enhancement), systemd started to automatically clean /tmp > directory daily. This is not something that I like as I prefer to decide > when to clean up and to manually perform the clean up. > > I have tried > > systemctl stop systemd-tmpfiles-clean.timer > systemctl disable systemd-tmpfiles-clean.timer > > The disabling apparently did not survived a reboot and the undesired > systemd service came back. > > I guess that I could mess with tmpfiles-clean config file but I am just > not interested in the service at all. What is the sure way method to > disable it for good? systemd-tmpfiles-clean does more that just removing stuff from /tmp. So changing the config is the only way to go. Just copy /usr/lib/tmpfiles.d/tmp.conf to /etc/tmpfiles.d/ and modify it as you like... Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature
Re: [arch-general] makepkg.conf CFLAGS
On Mon, 2 Jun 2014 23:53:38 +0600 Rashif Ray Rahman wrote: > On 2 June 2014 18:56, Yamakaky wrote: > > > >> I believe when the decision was made it was simply based on the fact > >> that being able to share is worth more for the community than local > >> optimization. > > > > PKGBUILDs and packages from repositories have to be portable, but it's > > not a requirement for self-build AUR packages. Who shares binary > > packages from AUR ? > > Anybody can share binary packages that they build off of AUR > buildscripts -- that is exactly what we allow by making these flags > the default. > > With local optimization, users end up spending time rebuilding. You > may build a bunch of packages and decide to share them from a repo, or > you may want help from somebody else with runtime problems that you're > having. > > There is no statistical backing here AFAIK, so if you feel strongly > about it, you are welcome to approach the pacman developers in order > to reach a new conclusion. > Remember also that gcc optimization flags make difference only for programs which run in or close to realtime. Examples include lapack/arpack, blender, or your own HPC code. For everything else advanced optimization via -march= and -O? flags yields no measurable performance increase. Even if you build e.g. thunderbird using -O1 for a generic x86_64 machine, you'll not notice any slowdown compared to an "optimized" build (actually, that's how I build all my local packages). Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature
Re: [arch-general] How do I _really_ fix the superblock?
On Sat, Jun 07, 2014 at 05:46:48PM +0200, Ralf Mardorf wrote:
> Date: Sat, 07 Jun 2014 17:46:48 +0200
> From: Ralf Mardorf
> To: arch-general@archlinux.org
> Subject: Re: [arch-general] How do I _really_ fix the superblock?
> X-Mailer: Evolution 3.12.2
>
> On Sat, 2014-06-07 at 09:59 -0500, Doug Newgard wrote:
> > The Beginner's Guide says: Warning: Using localtime may lead to several
> > known and unfixable bugs.
> >
> > If you're going to do something non-standard that's known to cause
> > problems, you have to expect things like this from time to time.
>
> "systemd, libsystemd and systemd-sysvcompat 213-6 from testing only
> solve the fstab issue, but they don't solve the superblock issue." -
> https://bugs.archlinux.org/task/40706
There has never been a "superblock" issue. There is something wrong with your
RTC/system clock. Depending on the filesystem this may be a problem or not. For
instance, ext{3,4} cares about superblock modification time, while ntfs does
not (iirc).
> now. I chose local time because I want the correct time, when I use the
> BIOS, e.g. to backup BIOS settingstamps.
And... your clock is not correct apparently. Besides, what does BIOS backup
have to do with a way your clock keep time?
--
Leonid Isaev
GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4
C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
pgpEy3a4KYQfx.pgp
Description: PGP signature
Re: [arch-general] How do I _really_ fix the superblock?
On Sat, Jun 07, 2014 at 06:23:49PM +0200, Ralf Mardorf wrote: > Date: Sat, 07 Jun 2014 18:23:49 +0200 > From: Ralf Mardorf > To: arch-general@archlinux.org > Subject: Re: [arch-general] How do I _really_ fix the superblock? > X-Mailer: Evolution 3.12.2 > > On Sat, 2014-06-07 at 12:12 -0400, Leonid Isaev wrote: > > your clock is not correct apparently. > > The clock provides the correct localtime. There's no issue caused by the > clock. The issue only appears for Arch Linux with systemd from the > repositories > version 212-3. It worked before: > > [rocketmouse@archlinux ~]$ grep systemd /var/log/pacman.log > [snip] > [2013-02-17 02:59] installed systemd (197-4) > [snip] > [2014-06-04 08:34] [PACMAN] upgraded libsystemd (212-3 -> 213-5) > [2014-06-04 08:34] [PACMAN] upgraded systemd (212-3 -> 213-5) > [2014-06-04 08:34] [PACMAN] upgraded systemd-sysvcompat (212-3 -> 213-5) > [snip] > [2014-06-07 17:19] [PACMAN] Running 'pacman -U > systemd-213-6-x86_64.pkg.tar.xz libsystemd-213-6-x86_64.pkg.tar.xz > systemd-sysvcompat-213-6-x86_64.pkg.tar.xz' > [2014-06-07 17:19] [PACMAN] upgraded libsystemd (213-5 -> 213-6) > [2014-06-07 17:19] [PACMAN] upgraded systemd (213-5 -> 213-6) > [2014-06-07 17:19] [PACMAN] upgraded systemd-sysvcompat (213-5 -> 213-6) > > And it always worked without a problem for all other Linux and FreeBSD > installs on my machines. Just out of curiosity, when exactly do you see the fsck warning: at each reboot, or when booting after some downtime? Also, how do you syncronize time: ntpd/chrony/timesyncd? > > If it's a new policy, then there's no reason to discuss this on the > mailing list. > There is no policy, just common sense... -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpQcZy6VVvrX.pgp Description: PGP signature
Re: [arch-general] How do I _really_ fix the superblock?
On Sat, Jun 07, 2014 at 06:49:58PM +0200, Ralf Mardorf wrote: > Date: Sat, 07 Jun 2014 18:49:58 +0200 > From: Ralf Mardorf > To: arch-general@archlinux.org > Subject: Re: [arch-general] How do I _really_ fix the superblock? > X-Mailer: Evolution 3.12.2 > > On Sat, 2014-06-07 at 12:43 -0400, Leonid Isaev wrote: > > Just out of curiosity, when exactly do you see the fsck warning: at > > each reboot, or when booting after some downtime? Also, how do you > > syncronize time: ntpd/chrony/timesyncd? > > I see the warning with each startup, it doesn't matter if I reboot or if > I boot after a long downtime. The clock is ok. I sync manually > > [rocketmouse@archlinux ~]$ cat /usr/local/bin/tool > #!/bin/bash > > # /usr/local/bin/tool > > case $1 in > [snip] > ntp) > ntpdate ntp.favey.ch > hwclock --set --date "$(date)";; > [snip] Just an advice: replace this with a continuously tunning ntpd or at least with ntpd -q. > > The warning about the wrong superblock time isn't an issue, the problem > is that with each startup the / partition is checked. I thought this is > caused by the wrong superblock time, but IIUC it's another bug. > That's actually interesting. Whether / will be fsck'ed or not depends on your mkinitcpio hooks (fsck) and kernel cmdline. What are them? Do you have "ro" in the cmdline? -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpdOAP_6fnZI.pgp Description: PGP signature
Re: [arch-general] Unwanted forced fsck at each startup - Was: How do I _really_ fix the superblock?
On Sat, Jun 07, 2014 at 10:34:12PM +0200, Ralf Mardorf wrote: > Date: Sat, 07 Jun 2014 22:34:12 +0200 > From: Ralf Mardorf > To: arch-general@archlinux.org > Subject: Re: [arch-general] Unwanted forced fsck at each startup - Was: How > do I _really_ fix the superblock? > X-Mailer: Evolution 3.12.2 > > On Sat, 2014-06-07 at 13:23 -0400, Leonid Isaev wrote: > > That's actually interesting. Whether / will be fsck'ed or not depends > > on your mkinitcpio hooks (fsck) and kernel cmdline. What are them? Do > > you have "ro" in the cmdline? > > The GRUB lines for my kernels all include 'ro'. > > [rocketmouse@archlinux ~]$ grep HOOKS /etc/mkinitcpio.conf | grep -v "#" > HOOKS="base udev autodetect modconf block filesystems keyboard fsck vboxhost" So, your / is being checked twice on boot... > > "1) Use the 'fsck' hook, use 'rw' on the kernel commandline. > 2) Don't use the 'fsck' hook, use 'ro' on the kernel commandline." - > https://bbs.archlinux.org/viewtopic.php?pid=1307895#p1307895 > > So I should remove fsck from the hooks? Since you are seeing the fsck warning even after an extended downtime, I can think of two possibilities: 1. The superblock mod time is _really_ wrong (like in 2020), that is OS does something strange. You can check this by running "tune2fs -l" or dumpe2fs from a live environment, possibly disabling your timesync tool for this one experiment. 2. Something happens in between the two runs of fsck. I'd remove the fsck hook to let systemd check the filesystems and see if that helps. > If so, why didn't it cause the issue before the systemd update? > I don't know. > Regards, > Ralf > > Off-topic PS: > > Just an advice: replace this with a continuously tunning ntpd or at > > least with ntpd -q. > > Is this useful for a DAW? Part of the audio tuning could be turning off > Internet connections, but at least I will run as less services as > possible. Ok, the -q "ntpd will not daemonize and will exit after the > clock is first synchronized" seems to be something I could use. > I meant "running", not "tunning". Also, I can only suspect what you mean by DAW. Anyway, ntpd daemon can handle intermittent network access just fine... Unless you have an extremely CPU/memory-constrained system, you really should use the daemon IMHO because it offers continuous time synchronization, etc. -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpLw8Tckygaq.pgp Description: PGP signature
Re: [arch-general] [PATCH 1/1] systemd: restart services after update
Hi,
On Wed, Jun 11, 2014 at 12:15:18PM +0200, Christian Hesse wrote:
> Date: Wed, 11 Jun 2014 12:15:18 +0200
> From: Christian Hesse
> To: arch-general
> Cc: Christian Hesse
> Subject: [arch-general] [PATCH 1/1] systemd: restart services after update
> X-Mailer: git-send-email 2.0.0
>
> From: Christian Hesse
>
> ---
> systemd.install | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/systemd.install b/systemd.install
> index 5c370f7..11e97bc 100644
> --- a/systemd.install
> +++ b/systemd.install
> @@ -27,6 +27,12 @@ maybe_reexec() {
>
>if sd_booted; then
> systemctl --system daemon-reexec
> +
> +for SERVICE in systemd-journald systemd-logind systemd-machined
> systemd-networkd systemd-resolved systemd-udevd; do
> + if systemctl is-active ${SERVICE} >/dev/null; then
> +systemctl restart ${SERVICE}
> + fi
> +done
>fi
> }
Are you sure it's a good idea to restart things like that? Because this assumes
that these daemons are independent -- is this a valid assumption? It seems that
systemctl daemon-reexec _should_ reexec itself and its flock of helpers...
Thanks,
--
Leonid Isaev
GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4
C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
pgpdd1dQwBZmd.pgp
Description: PGP signature
[arch-general] inetutils and the 'base' group
Hi, Is there a reason why core/inetutils is in base group, i.e. which packages implicitly rely on it? It was added to base around Aug. 2011 ago, I think because of hostname(1), but shouldn't this functionality be now provided by hostnamectl? Thanks, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpjkLWHlDer2.pgp Description: PGP signature
Re: [arch-general] inetutils and the 'base' group
On Mon, Jun 16, 2014 at 08:31:42PM -0400, Daniel Micay wrote: > Date: Mon, 16 Jun 2014 20:31:42 -0400 > From: Daniel Micay > To: arch-general@archlinux.org > Subject: Re: [arch-general] inetutils and the 'base' group > User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 > Thunderbird/24.6.0 > > On 16/06/14 07:35 PM, Leonid Isaev wrote: > > Hi, > > > > Is there a reason why core/inetutils is in base group, i.e. which > > packages implicitly rely on it? It was added to base around Aug. 2011 ago, I > > think because of hostname(1), but shouldn't this functionality be now > > provided > > by hostnamectl? > > > > Thanks, > > It's likely just in base because it was viewed as convenient. You can > temporarily change the hostname with `sysctl kernel.hostname=foo` alone > anyway. Yes, but the hostname binary may be queried by scripts, like startx. > > AFAIK it's a bug if there's an implicit dependency on base, although > it's not clear if an implicit make dependency on base is allowed as it > is for base-devel. I thinks so, and this seems convenient. Otherwise everything should depend on glibc, for example. This implicit behavior is the reason why base should be small. Hence my question... Sincerely, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpdPUHzYcQPH.pgp Description: PGP signature
[arch-general] No libutil.a in core/glibc
Hi,
Why is there no static libutil (libutil.a) in the glibc package? The
PKGBUILD has "options=(staticlibs)" which is supposed to keep *.a files, and
indeed, there are some static libraries like libpthread{,_nonshared}.a. Was
static libutil removed by upstream?
Thanks,
--
Leonid Isaev
GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4
C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
pgpuqE7AmZ2ty.pgp
Description: PGP signature
Re: [arch-general] [draft] xorg-server 1.16 is now available
Hi, [ cross-posting to arch-general ] On Fri, Jul 25, 2014 at 03:59:27PM +0200, Laurent Carlier wrote: > The new version comes with the following changes: > * X is now rootless with the help of systemd-logind, this also means that it > must be launched from the same virtual terminal as was used to log in. Please > note that launching X through a login-manager (gdm, kdm, ...) doesn't yet > provide rootless access. The old root execution behavior can be restored > through the Xorg.wrap config file (man xorg.wrap). Note that this update is not seemless because it breaks virtual machines with vesa (no KMS, so can not access /dev/mem). The documentation says that Xorg will autodetect whether or not to drop root privs, but it doesn't. Forcing X to run as root via Xwrapper.config does help, but neither this file nor /etc/X11/X11 are part of the package. Is it possible to at least have the latter directory in xorg-server? Otherwise, great news! Thanks, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpNlqm2GrN4H.pgp Description: PGP signature
Re: [arch-general] [draft] xorg-server 1.16 is now available
On Sat, Jul 26, 2014 at 08:54:21AM +0200, Laurent Carlier wrote: > Le samedi 26 juillet 2014, 03:11:45 Karol Blazewicz a écrit : > > I can start only one rootless X session at a time. If I want to start > > a second one while the first one is running, I have to use 'sudo > > startx'. > > I'm logging into tty and starting X as a user. > > > > Did I mis-configure something or is it a "feature'? Can you start > > multiple X sessions simultaneously with xorg 1.16? > > I have not yet found how to do this with xorg 1.16 in rootless mode. Multiple > X sessions should work flawlessly with root rights. Not really, in general. For me, Xserver 1.16 with root rights works only on KMS-less systems. In other setups I have tested, X simply segfaults if running as root. This happens on real hw as well as in vmware player (which provides KMS). In the latter case I had to downgrade to xorg-server 1.15 to get my desktop back (also, I do not use proprietary vmware tools). Here are the errors on a real machine with hybrid AMD/Intel graphics: -- $ lspci | grep VGA 00:02.0 VGA compatible controller: Intel Corporation 4th Gen Core Processor Integrated Graphics Controller (rev 06) 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Venus XT [Radeon HD 8870M / R9 M270X] (rev ff) $ grep "(EE)" /var/log/Xorg.0.log (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 2484.378] (EE) systemd-logind: failed to take device /dev/dri/card0: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. [ 2485.302] (EE) /dev/dri/card0: failed to set DRM interface version 1.4: Permission denied [ 2485.305] (EE) Failed to load module "modesetting" (module does not exist, 0) [ 2485.305] (EE) Failed to load module "fbdev" (module does not exist, 0) [ 2485.305] (EE) Failed to load module "vesa" (module does not exist, 0) [ 2485.376] (EE) systemd-logind: failed to take device /dev/dri/card0: Device already taken [ 2485.376] (EE) /dev/dri/card0: failed to set DRM interface version 1.4: Permission denied [ 2491.936] (EE) [ 2491.936] (EE) Backtrace: [ 2491.937] (EE) 0: /usr/bin/Xorg.bin (xorg_backtrace+0x56) [0x5938f6] [ 2491.937] (EE) 1: /usr/bin/Xorg.bin (0x40+0x197af9) [0x597af9] [ 2491.937] (EE) 2: /usr/lib/libc.so.6 (0x7f88e4e55000+0x33df0) [0x7f88e4e88df0] [ 2491.937] (EE) 3: /usr/lib/libc.so.6 (0x7f88e4e55000+0x128696) [0x7f88e4f7d696] [ 2491.937] (EE) 4: /usr/bin/Xorg.bin (0x40+0xa14e8) [0x4a14e8] [ 2491.937] (EE) 5: /usr/lib/libdbus-1.so.3 (dbus_connection_dispatch+0x3f1) [0x7f88e69055b1] [ 2491.937] (EE) 6: /usr/lib/libdbus-1.so.3 (0x7f88e68f5000+0x10805) [0x7f88e6905805] [ 2491.937] (EE) 7: /usr/bin/Xorg.bin (0x40+0x9ae09) [0x49ae09] [ 2491.937] (EE) 8: /usr/bin/Xorg.bin (WakeupHandler+0x6b) [0x43c3ab] [ 2491.937] (EE) 9: /usr/bin/Xorg.bin (WaitForSomething+0x1c7) [0x590d27] [ 2491.937] (EE) 10: /usr/bin/Xorg.bin (0x40+0x374f1) [0x4374f1] [ 2491.937] (EE) 11: /usr/bin/Xorg.bin (0x40+0x3b866) [0x43b866] [ 2491.937] (EE) 12: /usr/lib/libc.so.6 (__libc_start_main+0xf0) [0x7f88e4e75000] [ 2491.937] (EE) 13: /usr/bin/Xorg.bin (0x40+0x25d0e) [0x425d0e] [ 2491.937] (EE) [ 2491.937] (EE) Segmentation fault at address 0x0 [ 2491.937] (EE) [ 2491.937] (EE) Caught signal 11 (Segmentation fault). Server aborting [ 2491.937] (EE) [ 2491.937] (EE) [ 2491.937] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information. [ 2491.937] (EE) [ 2493.888] (EE) systemd-logind: ReleaseControl failed: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. [ 2493.888] (EE) Server terminated with error (1). Closing log file. -- Somehow, I can not make sense of the above error (X runs as root, so it can write to /var/log/ but lacks permissions for a device?). Any ideas? Thanks, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpyH0jXSKnSY.pgp Description: PGP signature
Re: [arch-general] [draft] xorg-server 1.16 is now available
On Sat, Jul 26, 2014 at 11:09:32PM +0200, Laurent Carlier wrote: > [...] > Probably a bug related to PRIME, you should probably open an upstream bug > report. Yes. I'll wait for linux 3.16 and then do if the problem is still there. Although, this looks more like a kernel/systemd issue. Here is a log from a rootless X: -- [ 143.639] (II) xfree86: Adding drm device (/dev/dri/card0) [ 143.639] (II) systemd-logind: got fd for /dev/dri/card0 226:0 fd 8 paused 0 [ 143.639] (II) xfree86: Adding drm device (/dev/dri/card1) [ 143.640] (II) systemd-logind: got fd for /dev/dri/card1 226:1 fd 9 paused 0 [ 143.640] (--) PCI:*(0:0:2:0) 8086:0416:1028:05cc rev 6, Mem @ 0xf640/4194304, 0xd000/268435456, I/O @ 0xf000/64 [ 143.640] (--) PCI: (0:1:0:0) 1002:6821:1028:05cc rev 0, Mem @ 0xe000/268435456, 0xf7d0/262144, I/O @ 0xe000/256, BIOS @ 0x/131072 -- Card0 = radeon; card1 = intel: -- $ cat /sys/class/drm/card0/device/power/runtime_status suspended $ cat /sys/class/drm/card1/device/power/runtime_status active $ xrandr --listproviders Providers: number : 2 Provider 0: id: 0x82 cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 4 outputs: 5 associated providers: 0 name:Intel Provider 1: id: 0x59 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 6 outputs: 4 associated providers: 0 name:radeon -- Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpgEyyQibbWG.pgp Description: PGP signature
Re: [arch-general] [draft] xorg-server 1.16 is now available
On Sat, Jul 26, 2014 at 11:40:18PM +0200, Laurent Carlier wrote: > [...] > > Can you try to boot with the kernel parameter drm.rnodes=1 ? > Yes, but this doesn't make a difference. X still crashes when tries to run as root. However, after a closer look, I found this in auth.log (sorry, forgot to mention before): -- 2014-07-26T23:09:56.000-04:00 borei polkitd[823]: Loading rules from directory /etc/polkit-1/rules.d 2014-07-26T23:09:56.000-04:00 borei polkitd[823]: Loading rules from directory /usr/share/polkit-1/rules.d 2014-07-26T23:09:56.000-04:00 borei polkitd[823]: Finished loading, compiling and executing 1 rules 2014-07-26T23:09:56.000-04:00 borei polkitd[823]: Acquired the name org.freedesktop.PolicyKit1 on the system bus 2014-07-26T23:09:59.000-04:00 borei systemd-logind[415]: kernel does not support evdev-revocation -- What's the need for polkit when needs_root_rights = yes? Thanks, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpTPyR2jQYtc.pgp Description: PGP signature
Re: [arch-general] Improve the filesystem package
On Fri, Aug 01, 2014 at 12:14:21PM +0200, Yamakaky wrote:
> Hi
>
> I see some possible improvements to the filesystem package to use some of
> the recent improvements to systemd. I don't know if they are already
> planned.
>
> All the empty directories and the links could be replaced by a tmpfiles.d
> file, like /usr/lib/tmpfiles.d/archlinux.conf.
And what happens if my root filesystem is mounted read-only? So, please let's
not allow tmpfiles to touch /etc...
>
> /etc/{group,gshadow,passwd,shadow} could be removed as the base users and
> groups are already created by the upstream sysusers.d files. The
> arch-specific ones (like bin or daemon) could be created by
> /usr/lib/sysusers.d/archlinux.conf.
>
> The others /etc/ files could be moved to /usr/share/etc/ and copied as
> needed to /etc using tmpfiles.d files.
>
> A filesystem.install file could launch systemd-tmpfiles and systemd-sysusers
> to update the local configuration when the package is updated.
>
> In the end, filesystem would contain only tmpfiles.d and sysusers.d files +
> /usr/share/etc.
>
> I can make a draft of this package if you want.
And all that assumes that you can execute systemd-sysusers, no?
Cheers,
--
Leonid Isaev
GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4
C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
pgpMFRGzSgbMK.pgp
Description: PGP signature
Re: [arch-general] Improve the filesystem package
On Fri, Aug 01, 2014 at 07:10:10PM +0200, Yamakaky wrote: > >And all that assumes that you can execute systemd-sysusers, no? > > Oh, I see, you are talking about emergency boot ? > Yes. What you suggest is OK for an update on a working system, but what about a fresh install or rescue? You call pacstrap to install into a directory, but systemd is installed _after_ filesystem and a bunch of other packages which expect all those directories. IMHO, the idea of a stateless system applies to a narrow usecase like coreos, when you magically obtained a working system (and systemd), and now can do all the cool stuff. However, coreos is not a general-purpose distro like Arch. On top of that, I remember that quite recently it was considered a no-no for a daemon to write to /etc... Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpIvvcOFCTYs.pgp Description: PGP signature
Re: [arch-general] [arch-dev-public] linux 3.16 in [testing]
Hi, On Wed, Aug 13, 2014 at 06:44:39PM +0200, Thomas Bächler wrote: > Am 13.08.2014 um 17:29 schrieb Damjan Georgievski: > > On 13 August 2014 17:26, Damjan Georgievski wrote: > >> yey > >> thanks for CONFIG_USER_NS=y > > > > ahh no, I'm stupid. > > Checked it on another machine and got excited before hand > > :/ > > > > anyway. is there a reason this is not enabled now? > > all the mainstream distros hae it enabled now Fedora, RHEL/CentOS 7, > > Ubuntu and Debian (at least on the backported kernel) > > I'd think about it, if the feature wasn't entirely useless. Despite the > lack of official documentation, I found a document that described how it > worked. After reading that document I concluded that the feature is a > huge potential security risk with no actual benefit. Interestinig. Could you please provide a link? > > If you give me a valid use case for USER_NS, I might reconsider, but > every use case I can imagine is crushed by the limitations of the > implementation. As you know, user_ns is a necesary prerequisite for unpriviileged containers: https://www.stgraber.org/2014/01/17/lxc-1-0-unprivileged-containers/ . AFAIU, currently only Ubuntu 14.04 supports those. However, I agree with you that CONFIG_USER_NS is better left disabled in -ARCH kernels. After all, people using containers should be able to compile a custom kernel... Thanks, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgp56_oGHbyXw.pgp Description: PGP signature
Re: [arch-general] [arch-dev-public] linux 3.16 in [testing]
On Wed, Aug 13, 2014 at 08:21:32PM +0300, Mihamina Rakotomandimby wrote: > Easing the work by defaulting to a ready-to-work kernel would be nice. I think that LXC is used by minority of users (myself included). So, enabling USER_NS by default would put the rest of (unsuspecting) users in unnecessary danger. OTOH, configuring an LXC container already requires some understanding. Compared to that, building a custom kernel is really not a major barrier. Of course, the user namespace stuff will never become 'stable' if nobody uses it... Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpz6CFRr3OKD.pgp Description: PGP signature
Re: [arch-general] qemu-vm : access to KVM kernel denied
On Sun, Aug 17, 2014 at 11:30:38AM +0200, arnaud gaboury wrote: > I found my entries about this topic, but no clear answer. > > As user, I want to install a VM with virt-install. > $ virt-install --connect qemu:///system --LONG list of options > > Error : could not access KVM kernel module: permission denied. Running > the above command as root returns the same. > > My configuration: > martinus@gerbillous ➤➤ ~ % uname -r > 3.16.1-1-ARCH > martinus@gerbillous ➤➤ ~ % ls -al /dev/kvm > crw-rw+ 1 root kvm 10, 232 Aug 17 11:05 /dev/kvm > martinus@gerbillous ➤➤ ~ % groups martinus > adm wheel video audio kalu libvirt qemu kvm martinus You don't need to be in 'kvm' group to use /dev/kvm. What does 'getfacl /dev/kvm' say? Can you run a plain qemu-system-? Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpnNXmxKY1pH.pgp Description: PGP signature
Re: [arch-general] qemu-vm : access to KVM kernel denied
On Sun, Aug 17, 2014 at 05:00:44PM +0200, arnaud gaboury wrote: > martinus@gerbillous ➤➤ ~ % getfacl /dev/kvm > getfacl: Removing leading '/' from absolute path names > # file: dev/kvm > # owner: root > # group: kvm > user::rw- > user:martinus:rw- > group::rw- > mask::rw- > other::--- So, permissions on /dev/kvm look OK. Actually, you can remove yourself from the 'kvm' group. > > >From man virt-install : > -- > qemu:///system > For creating KVM and QEMU guests to be run by the system libvirtd > instance. This is the default mode that virt-manager uses, and > what most KVM users want. > > qemu:///session > For creating KVM and QEMU guests for libvirtd running as the > regular user. > -- > > $ >> $ virt-install --connect qemu:///session I have no idea what this means because I never used libvirt (only qemu directly). Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpvaNd8ji_k1.pgp Description: PGP signature
Re: [arch-general] Improve the filesystem package
On Wed, Aug 20, 2014 at 02:42:27PM +0200, Alain Kalker wrote: > On 08/20/2014 02:04 PM, Alain Kalker wrote: > >Also, why ship the /etc/shadow, /etc/gshadow files at all? > >AFAIK, nothing is supposed to mess with the shadow files anyway, except > >pwconv and grpconv (for initially converting a freshly installed, > >non-shadow system into one using shadow files), after which these files > >should be managed by the shadow system itself, in response to > >adding/removing/changing users and groups using the designated tools. > > From `man pwconv`: > > > Each program acquires the necessary locks before conversion. Except that sometimes a package installs files owned by a _new_ user. So one needs some "basic" groups to exist _before_ high-level packages are unpacked. Shipping these users/groups only in un-shadowed files will lead to pwck/grck complaints... HTH, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpaI_A9p0_qL.pgp Description: PGP signature
Re: [arch-general] [arch-dev-public] systemd 216 coming soon to testing
Hi, [sorry for cross-posting] On Wed, Aug 20, 2014 at 02:25:24PM -0400, Dave Reisner wrote: > Full NEWS file: > > http://cgit.freedesktop.org/systemd/systemd/tree/NEWS This changelog says that: * journald will no longer forward all local data to another running syslog daemon. This change has been made because rsyslog (which appears to be the most commonly used syslog implementation these days) no longer makes use of this, and instead pulls the data out of the journal on its own. Since forwarding the messages to a non-existent syslog server is more expensive than we assumed we have now turned this off. If you run a syslog server that is not a recent rsyslog version, you have to turn this option on again (ForwardToSyslog= in journald.conf). This is going to break syslog-ng... So is it possible to patch journald.conf and enable ForwardToSyslog in the package? Thanks, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpU3zf33QwIH.pgp Description: PGP signature
Re: [arch-general] [arch-dev-public] systemd 216 coming soon to testing
On Thu, Aug 21, 2014 at 10:21:49AM -0500, Bigby James wrote: > On 08/20, Leonid Isaev wrote: > > > > This changelog says that: > > * journald will no longer forward all local data to another running syslog > > daemon. This change has been made because rsyslog (which appears to be the > > most commonly used syslog implementation these days) no longer makes use > > of > > this, and instead pulls the data out of the journal on its own. Since > > forwarding the messages to a non-existent syslog server is more expensive > > than we assumed we have now turned this off. If you run a syslog server > > that > > is not a recent rsyslog version, you have to turn this option on again > > (ForwardToSyslog= in journald.conf). > > > > This is going to break syslog-ng... So is it possible to patch journald.conf > > and enable ForwardToSyslog in the package? > > > > Thanks, > > It seems this is just a change in the default settings, nothing more. I know, but not everyone follows systemd-devel. So, just updating systemd would lead to syslog "mysteriously" not logging anything... [rant] Besides, I don't understand the motivation that rsyslog "pulls the data out of the journal on its own". If this is via the "imjournal" module, then it's a bogus argument because even the official documentation basically discourages the use of this module. [/tant] [1] http://www.rsyslog.com/doc/imjournal.html Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpFCq4IDcaPA.pgp Description: PGP signature
Re: [arch-general] [arch-dev-public] systemd 216 coming soon to testing
On Thu, Aug 21, 2014 at 11:56:06AM -0500, Bigby James wrote: > > > It seems this is just a change in the default settings, nothing more. > > > > I know, but not everyone follows systemd-devel. So, just updating systemd > > would > > lead to syslog "mysteriously" not logging anything... > > Sure, *if* you didn't already explicity set journald to use an external > logging > daemon. If you did, then the update is just going to create a *.pacnew file > that > can be deleted. In other words, the problem is improper configuration on the > part of the user, not impropriety on the part of upstream. > > I use syslog-ng myself, and it seems to me that if I'm going to be deviating > from the defaults set by upstream and the Arch devs then it falls to me to pay Using syslog-ng is not "deviating from the defaults". So far the default was to send things to _a_ syslog -- no modification of journald.conf was required (check the old manpages). Therefore, you won't get a pacnew file, and the new config will be quietly put in place, breaking existing installations for no valid technical reason. Anyway, let's not argue about the semantics, it's not a big deal of course. Hopefully, this thread saves someone a bit of hairpulling :) Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpScBICVVdOh.pgp Description: PGP signature
Re: [arch-general] Building in docker?
On Wed, Sep 03, 2014 at 09:04:37AM +0200, Magnus Therning wrote: > For various reasons I'm looking into not using `makechrootpkg` when > building the 200+ packages I put into a non-official repo. Obviously > it's important to keep the building environment separate from my > ordinary system environment. Going to full virtualisation is > definitely overkill and the only containers I know of are chroots and > docker. If by chroot you mean also nspawn, then it is mostly equivalent to docker and lxc. The only thing bad about systemd-nspawn is its lack of easy config through files (it only supports cmdline switches which is ridiculously cumbersome). Also, docker is more complex than a plain lxc-tools approach. So, I would go with lxc as the simplest and most flexible solution. In fact, that's how I build my packages. > > Docker has some nice attributes, in particular no need for root > access. However, I don't know a whole lot about it, so I wonder are Where do you take this from? Rootless containers require a specific host kernel configuration (which -ARCH kernels don't have). Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpNjCL6OfLXw.pgp Description: PGP signature
Re: [arch-general] Building in docker?
On Wed, Sep 03, 2014 at 10:26:11PM +0200, Magnus Therning wrote: > Oki, I've never looked at lxc, I was under the impression that docker > used to build on lxc in the past. Is that not true any longer? It was true, yes, but I don't think it is now. Although, I can't find a link ATM. > Is there a template included for Arch? That would be quite nice > because building the docker image for Arch is a bit ugly I'd say Yes. It is a bit messy IMHO because it is being maintaned by several people... So, I always manually create my containers, but then again, I always have a config lying around. > > Finally, what about running a 32bit container on a 64bit host? I've > not managed to find any indication that this is officially supported > in docker, but it seems to work just fine. This is supported. > > > > Docker has some nice attributes, in particular no need for root > > > access. However, I don't know a whole lot about it, so I wonder are > > > > Where do you take this from? Rootless containers require a specific > > host kernel configuration (which -ARCH kernels don't have). > > Well, I'm probably imprecise here. What I meant was that after the > service has been started (which requires root) any user in the docker > group can start images. Yeah, I kinda dislike these "daemon + privileged group" things -- reminds me of polkit. With lxc, you'll need to have a container running and connect to it via SSH or VNC. For me this is OK because my build container is on a desktop and I usually access it from a laptop... HTH, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpYzW8WQRCSU.pgp Description: PGP signature
Re: [arch-general] Building in docker?
On Thu, Sep 04, 2014 at 07:24:36AM +0200, Magnus Therning wrote: > As always complex doesn't automatically translate to complicated ;) > > In this particular case I had no issues with following the > instructions I found on docker. While when spending the same amount > of time on getting lxc to work I get stuck almost immediately: > > > % lxc-create -n test -t archlinux > lxc_container: No mapping for container root > lxc_container: Error chowning /home/magnus/.local/share/lxc/test/rootfs to > container root > lxc_container: Error creating backing store type (none) for test > lxc_container: Error creating container test > > > And quick googling didn't turn up anything useful. Reading through > the Linux Containers page [1] didn't help either. No, this will not work because lxc-create needs root privileges for a variety of things. You'll need to have user_ns enabled in the kernel to accomplish this as a normal user. Note, that docker is not much better, it's just uses a privileged daemon to do things. IIRC, currently running lxc-* as a normal user will work out-of-the-box only on an Ubuntu 14.04 host. Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgp7piC7vz3lA.pgp Description: PGP signature
Re: [arch-general] pacman-key issue
On Tue, Sep 09, 2014 at 08:42:38PM +0200, Frank Zimmermann wrote: > Good evening, > > I'm having trouble with my pacman-keyring which in the end prevents me from > installing signed packages. Here's the output: > pacman-key --populate archlinux > ==> Appending keys from archlinux.gpg... > ==> Locally signing trusted keys in keyring... > -> Locally signing key FOO > ==> ERROR: FOO could not be locally signed. > > Any hints? Something is wrong with your local keyring or the secret key. Did you run "pacman-key --init" and what does "pacman-key -l" show? Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpjhDH7PmyN1.pgp Description: PGP signature
Re: [arch-general] Location of the pacman database
On Wed, Sep 10, 2014 at 09:05:03PM +0200, Yamakaky wrote: > Le 10/09/2014 20:50, Joel Teichroeb a écrit : > >Generally, things that are written to are not stored in /usr. > > > >This page might help > > > >https://wiki.archlinux.org/index.php/arch_filesystem_hierarchy > > > > That's what I thought at first, but it's different. pacman db doesn't > contain runtime stuff, it's a description of the currently installed > packages. It's a bit like putting os-release in /usr/lib. I htink you are right about the local DB (/var/lib/pacman/local). However, /var/lib/pacman/sync should probably stay in /var (I don't need a rw root FS to resync package DB). Anyway, I think you should open a feature request at the bugtracker. Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgph4N8WfVFUU.pgp Description: PGP signature
Re: [arch-general] Location of the pacman database
On Sat, Sep 13, 2014 at 03:55:26PM +0200, Tobias Hunger wrote: > On Wed, Sep 10, 2014 at 11:59 PM, Neven Sajko wrote: > > But that task is not only about the filesystem location of the Pacman DB. > > It could be useful to open a separate bugreport just for that one issue. > > For what reason should the pacman DB be moved if not to enable new features > like the factory reset or image based installation? > > I can file separate bugs for all the items listed in > https://bugs.archlinux.org/task/41863 , > but I personally do not think it makes a lot of sense. Yeah, that's what the 1st response in the bug report basically said: pacman DB location is a cosmetic detail. Also, note that systemd features like factory reset and/or atomic updates make no sense in the context of a rolling-release distro like Arch (or any distribution for that matter), so I doubt that they can be a sufficient motivation for this DB move... > > Best Regards, > Tobias Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgp73KTVckdoP.pgp Description: PGP signature
Re: [arch-general] Location of the pacman database
On Sun, Sep 14, 2014 at 11:15:13PM +0200, Nowaker wrote: > At this point /var/lib/pacman/local defines the current state of /usr. > It's not "variable" - you write to /var/lib/pacman/local if and only if > you write to /usr. The description of /usr on wiki perfectly describes > why /var/lib/pacman/local really belongs there: So, files in (now) /usr/lib/pacman/local contain filelists of packages, yes? If you wipe /var, lots of packages will have missing files... > - move /var/lib/pacman/local/ to /usr > - move the default pacman.conf and mirrorlist to /usr/share > - provide tmpfiles.d to copy those files to /etc What about pacman keyring? Also note that your custom keys should be packaged as well and resigned on-boot. > If I'm not mistaken, /usr/share and tmpfiles.d are really trivial and > wouldn't affect users in any way. That'd be a few additional files > somewhere in the filesystem without any effect on existing machines. Or > I'm wrong? This is madness. I remember sometime ago there was a witchhunt against daemons that write to /etc (cups is the worst offender). So why is it OK for systemd to do so? I personally don't want systemd to come anywhere near my /etc. Please package the tmpfiles.d/sysusers stuff with virtkick or whatever, but not with pacman. Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpmADioTU9YG.pgp Description: PGP signature
Re: [arch-general] Location of the pacman database
On Mon, Sep 15, 2014 at 12:53:40AM +0200, Nowaker wrote: > Good point. I just did `pacman -Ql |grep -F ' /var'` to see how many > files there are. 99.7% of them are directories only, though. Are > tmpfiles.d supposed to create directories in /var too? Docs mention > using tmpfiles.d to init /tmp or /run, not /var though. But I guess > stateless systemd would always provide tmpfiles for that. Yes, those are mostly dirs. And you can't create them through tmpfiles because it's going to be a mess. But breaking pacman -Qk is relatively harmless, the bigger question is what to do with all the files in var (e.g. exim mailspools)? Wiping /var is not an option on a workstation/server and is OK only in special cases, like kiosk-type systems or Fedora installations (which are broken by default anyway) :). AFAIK, this has not been publicly discussed on systemd-devel. > > What about pacman keyring? Also note that your custom keys should > > be packaged as well and resigned on-boot. > > I wasn't aware of that. I only refer to what the OP requested and that > didn't sound complicated at all. Now it does. Of course, depending on your paranoia (and amount of free time), you can ask whether keyring should be shared among snapshots and similar questions... > Please note I'm not a huge fan of systemd. I'd rather Arch hadn't > married systemd back then. But since it has already happened, many > parts of Arch make use of systemd (e.g. netctl), there are several > systemd contributors amongst Arch Linux developers, it'd be good to > make use of various systemd features. As long as they are not costly > to implement, of course. And this "factory reset" feature indeed seems > to be costly. systemd's factory reset and atomic upgrades were explicitly stated to be useful only in special situations, like embedded systems. Just because Archlinux systemd package enables them doesn't mean that the entire distribution should be change around. Implementation is easy, support in all usecases is hard. I mean, Archlinux is not CoreOS... Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpFZosgaJcCg.pgp Description: PGP signature
Re: [arch-general] Location of the pacman database
Hi, On Mon, Sep 15, 2014 at 08:28:22AM +0200, Tobias Hunger wrote: > On Sep 15, 2014 1:56 AM, "Leonid Isaev" wrote: > > systemd's factory reset and atomic upgrades were explicitly stated to be > useful > > only in special situations, like embedded systems. Just because Archlinux > > systemd package enables them doesn't mean that the entire distribution > should > > be change around. > > Yes, these are features for special use cases, I am not arguing that. > > I would still like these features to be easy to implement on Arch, provided > the required changes do not harm the traditional setups. > > > Implementation is easy, support in all usecases is hard. I mean, > Archlinux is > > not CoreOS... > > I do not think the changes in my bug report carry a support overhead. My only point is that moving pacman DB around is the least difficult thing to deal with when it comes to bringing factory-reset and friends to Archlinux. I don't object to this move by itself, but the motivation seems ill-defined to me. Moreover, reshuffling things around will break lots of scripts our there that expect /var/lib/pacman/local to be populated... Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpFYaVKHO1TF.pgp Description: PGP signature
Re: [arch-general] Location of the pacman database
Hi, On Mon, Sep 15, 2014 at 07:32:51AM +0200, Tobias Hunger wrote: > As I understand this, systemd expects daemons to deal with no settings in > /etc and /var. /var stores files, not settings. Most daemons will run OK with empty /var. But what do you do with the files? Some kind of rsync gluework? > I do not consider this a problem. When you use somebodies images you need > to trust that person. I do not consider trusting the keys that person > provides to be a problem. But it is a problem which has already been discussed. If you have N images, and 1 has its key stolen, all N are in danger. So, it's not about (not) trusting the developer. > > > This is madness. I remember sometime ago there was a witchhunt > > > against daemons that write to /etc (cups is the worst offender). So > > > why is it OK for systemd to do so? I personally don't want systemd > > > to come anywhere near my /etc. Please package the > > > tmpfiles.d/sysusers stuff with virtkick or whatever, but not with > > > pacman. > > Any privileged process can mess with /etc at any time. With factory reset > at least you get a pristine copy to compare the files in /etc against. Sure, and then we call it malicious... What do you call pristine? The files shipped on a livecd? Or an empty default configs shipped with daemons? So far, there are only things like groups/users, but those are trivialities. > Arch did embrace systemd, it should make it easy to use all its features. I > am not proposing to enable them by default. We already have enabled by default ldconfig.service enabled, systemd-update-done.service, etc, which messed a number of my containers. Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgptY4PyahmIJ.pgp Description: PGP signature
Re: [arch-general] Location of the pacman database
Hi Tobias, Thanks for the explanation. A few questions though -- sorry. On Mon, Sep 15, 2014 at 09:37:40PM +0200, Tobias Hunger wrote: > Well, I do not put the secret keyring into the images, so everything > should be fine. So, you never run pacman from within an image, or have sig. validation disabled in pacman.conf? > Pacman can still validate images, so everything is well. Do you mean packages in an image? > Local installs are not possible anyway. What's a local install? I mean, if you treat images atomically, why do you need pacman (and associated DB) at all? You should have it only on the buildhost that generates the images (I couldn't find details in your previous emails in this thread). > In the general case 'pristine' is probably the settings shipped by the > various arch linux packages. But those do not usually provide sane defaults, e.g. smartd.conf, dnsmasq.conf, syslog-ng.conf, wpa_supplicant.conf, and must be edited anyway. Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpt54QavFb7k.pgp Description: PGP signature
Re: [arch-general] A good time to switch to dash as /bin/sh?
On Fri, Sep 26, 2014 at 05:37:57AM +0800, lolilolicon wrote: > With the disclosure of the new bash bug (CVE-2014-6271, CVE-2014-7169), > it seems timely to bring this up. > > Dan added dash to core/base around seven years ago [1], intending the > eventually link /bin/sh to dash instead of bash. > > [1] > https://mailman.archlinux.org/pipermail/arch-dev-public/2007-November/003053.html > > We didn't make the switch, supposedly due to the bashism in our scripts > which had a #!/bin/sh shebang line? > > Seven years passed. > > Is there anything preventing us from making the switch from bash to dash > as /bin/sh now? We can then have dash provide sh instead. Yes -- due to the same reasons. Also, I don't understand what the switch has to do with the CVEs? If they are found -- good; if promptly fixed -- great. At the very least this means that people are looking at the code... Has anyone proven a theorem saying that no such bugs exist in dash (zsh, ksh, etc.)? Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpLFD8F0PBP1.pgp Description: PGP signature
Re: [arch-general] A good time to switch to dash as /bin/sh?
Hi, On Fri, Sep 26, 2014 at 07:30:29AM -0500, Drake Wilson wrote: > [...] > On my own desktop system, when I realized sh was bash recently I immediately > relinked it to dash and intend to keep it that way as long as I reasonably > can (I assume some things may break, in the current state; I'm willing to > deal with that on my own for now). Guys, please stop this witch hunt. If you don't trust bash, then get rid of it, but don't forget that: --- $ head -n1 /usr/bin/mkinitcpio #!/bin/bash --- So, yes ArchLinux core tools use and will continue to use 'bashisms' because they are convenient. The bugs which started this discussion are not a big deal anyway. They will only affect scripts that don't properly sanitize the input. Such scripts have bigger problems to worry about IMHO. The SSH-related issue is also insignificant because the bug will be triggered post-auth... Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpEm_qlnUdLv.pgp Description: PGP signature
Re: [arch-general] A good time to switch to dash as /bin/sh?
Hi, On Fri, Sep 26, 2014 at 03:57:54PM -0500, Doug Newgard wrote: > Yes, it's this paranoia that I've been trying to cut through in this thread > to get people to start discussing things rationally. Just an FYI for people running their own DHCP servers: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2014q3/008859.html . That said, an up-to-date Arch install should be relatively safe. Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpk5dm8JiL_k.pgp Description: PGP signature
Re: [arch-general] fdisk vs. gdisk for GPT partitioning
On Tue, Dec 16, 2014 at 08:15:26PM +0100, Bardur Arantsson wrote: > On 2014-12-16 19:58, Sebastiaan Lokhorst wrote: > > Hello everyone, > > > > Since more than a year now, fdisk (provided by util-linux) has had GPT > > support. This theoretically makes gdisk a duplicate of fdisk, and we could > > replace gdisk with fdisk. > > > > Now, I'm not asking to drop gdisk or anything like that, but in an effort > > to clean up the Beginners' guide of the Arch Wiki, we want to use a single > > partitioning tool for both MBR and GPT partitioning instructions.[1] > > util-linux fdisk is able to provide this functionality, but we are not > > completely sure if it is stable by now (it should be, I think). > > Speaking from complete ignorance... do significant numbers of people > still use MBR for non-obsolete platforms/machines? Yes. The age of a machine has no relevance for deciding whether to use GPT (or UEFI in general). Whenever I use LVM and/or LUKS, I set it up over the block device (like /dev/sda), not partitions (like /dev/sda1). So, there is no partition table at all. In this case, using legacy BIOS saves me from lots of UEFI-related headache. And of course, this entire motto of GPT "we support 20TiB drives" is just silly... Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgptzAdvSs8a9.pgp Description: PGP signature
Re: [arch-general] fdisk vs. gdisk for GPT partitioning
On Sun, Dec 21, 2014 at 09:49:42PM +0100, Sebastiaan Lokhorst wrote: > Thanks everyone for your responses! It seems that gdisk is still favorable > for advanced tasks, but fdisk is can be used for basic tasks, as are > usually required by beginners. No, that was my point: for "advanced" tasks you need neither. I never read the beginners' guide, and don't care how it is formatted. I am just trying to un-confuse people regarding the whole GPT vs MBR thing... > 2014-12-21 20:54 GMT+01:00 Leonid Isaev : > > > Yes. The age of a machine has no relevance for deciding whether to use GPT > > (or > > UEFI in general). > > > > This is not true. Some low-end modern machines completely drop legacy BIOS > boot. So booting via UEFI is required, and thus GPT is required. I really doubt this. Are you saying that some vendors on purpose break such things as booting from an external USB key? For example, I have an ExoPC tablet running Arch 64bit. It is true, that there is no checkbox in UEFI config saying "legacy BIOS". However, GPT partitioning is _not_ required at all. So, I nuked the EFI partition, made the entire SSD a LUKS container, and happily boot with MBR. Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpZ7h3Hq2SiM.pgp Description: PGP signature
Re: [arch-general] fdisk vs. gdisk for GPT partitioning
On Mon, Dec 22, 2014 at 07:33:43AM +0100, Thomas Bächler wrote: > Am 21.12.2014 um 22:48 schrieb Leonid Isaev: > > On Sun, Dec 21, 2014 at 09:49:42PM +0100, Sebastiaan Lokhorst wrote: > >> Thanks everyone for your responses! It seems that gdisk is still favorable > >> for advanced tasks, but fdisk is can be used for basic tasks, as are > >> usually required by beginners. > > > > No, that was my point: for "advanced" tasks you need neither. I never read > > the > > beginners' guide, and don't care how it is formatted. I am just trying to > > un-confuse people regarding the whole GPT vs MBR thing... > > If you want to un-confuse people, you can really simplify the > instructions by using only fdisk in the beginner's guide. Then you have > the same tool for both GPT and MBR. I usually go with cfdisk(8) though. But in general, I'd recommend to use BIOS/MBR whenever possible... > >> This is not true. Some low-end modern machines completely drop legacy BIOS > >> boot. So booting via UEFI is required, and thus GPT is required. > > > > I really doubt this. Are you saying that some vendors on purpose break such > > things as booting from an external USB key? > > I have a firmware that boots from USB fine in UEFI mode, but _only_ if > it is formatted with MBR - it won't boot from GPT USB disks. Confusing, > right? Not really. I can tell that Win 7/8/8.1 installation DVD downloaded from MSDN are definitely not GPT-formatted. But, that's what happens on my tablet. Formally the firmware is UEFI, but I only use MBR partitioning. Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgp3ZMccPD7d7.pgp Description: PGP signature
Re: [arch-general] mutt and gnupg
On Sun, Dec 07, 2014 at 10:45:45AM +1300, Jason Ryan wrote: > Yes, but you do need to move to GPGME (or at least that was the only way I > restored that functionality). Why? Where is it written? > > Update your gpg configuration in your mutt files: > set crypt_use_gpgme = yes This variable can certainly be set. However, by itself it doesn't do anything to help mutt discover the running gpg-agent. > Then in your shell profile file, set a couple of variables: > export GPG_TTY=$(tty) > export GPG_AGENT_INFO=$HOME/.gnupg/S.gpg-agent This is also unnecessary. The first variable should anyway be set in the .bashrc (or similar). The 2nd one is not needed to be exported globally. The real solution would be for mutt to look for gpg-agent sockets. Currently, mutt just seems to check GPG_AGENT_INFO in env and ask for a passwd if it is not set. It follows that the simplest workaround is to change mutt invocation as -- $ env | grep GPG GPG_TTY=/dev/pts/4 $ GPG_AGENT_INFO="" mutt -- and leave muttrc alone. Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpKt88WpTScU.pgp Description: PGP signature
Re: [arch-general] mutt and gnupg
On Tue, Dec 23, 2014 at 10:44:35AM +1300, Jason Ryan wrote:
> So, we only disagree about the content of the variable; ie., it *has* to
> exist,
> but it doesn't matter what is in it, or even if it is empty…
Yes. However, I don't see why you need to export it globally and I also don't
understand why using the GPGME backend should help.
By looking at mutt src, it seems that GPGME backend (crypt-gpgme.c) uses the
same logic regarding the gpg-agent as the classic PGP backend (pgp.c). Namely,
both invoke !getenv("GPG_AGENT_INFO") to check if a gpg-agent is running.
Cheers,
--
Leonid Isaev
GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4
C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
pgpZr10I647wU.pgp
Description: PGP signature
Re: [arch-general] depends vs. optdepends
Hi, On Mon, Dec 29, 2014 at 07:20:42PM -0600, Troy Engel wrote: > On Mon, Dec 29, 2014 at 6:50 PM, Daniel Micay wrote: > > Arch currently uses optional dependencies even when it means that > > executables provided by the package aren't going to work with the > > minimal set of dependencies. The packages could be split up more to > > avoid this without pulling in more stuff, but it's not what packagers > > usually choose to it. It's a design choice left up to the packager, not > > a bug. > > Thank you - tribal knowledge that wasn't written down as an acceptable > standard to the Arch packaging. I have added your first sentence to a > note (and credited you in the comment) so that it's not tribal > anymore: > > https://wiki.archlinux.org/index.php/PKGBUILD#optdepends Just because something is written in a wiki doesn't make it rational > The reason this is complicated is anyone who comes into Arch from > (most) other distros where this is considered a bug needs to > understand Arch doesn't work by the same rules as all the others for > binary shared library resolution. I disagree with the SOP, but can > leave my opinion at the door. Well, other distros following certain packaging guidelines doesn't imply that Arch should follow them as well. If you subscribe e.g. to fedora-devel you'll see how much more complicated compared to Arch the packaging process in Fedora is (and this process is fr from perfect). And I am not even talking about Debian... There is a tradeoff of complexity vs some "breakage". So it's not about you agreeing or not with the status quo, it's about contributing a more rational alternative than the existing PKGBUILD. In your jasper bugreport, it would have helped if you provided a PKGBUILD with split-packages, like jasper-base and jasper-jiv with proper "conflicts" and "provides". At least that's what I would do... Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpnZSbyhvC5q.pgp Description: PGP signature
Re: [arch-general] makepkg as root
On Sat, Jan 03, 2015 at 03:45:35PM -0500, Christian Demsar wrote: > Removing asroot reduces flexibility. For instance, when making packages on a > live install usb. You'd have to create a new account and su into it. Why? Just do what Arch LiveCD has been doing for ages (i.e. having the 'arch' user). And regardless of makepkg, using an only-root system (even read-only) is asking for trouble. > > It seems like a projection of morals to me. Just because it's not good > practice to use root permissions when it's not necessary, doesn't mean it > won't ever be useful. makepkg uses fakeroot, there is simply no need to be running as a superuser. > > The argument for choice and freedom of the creators can also be successfully > used to justify DRM. Companies are free to produce whatever crap they want. Unless you are a FSF (or RMS) fanatic, there is nothing wrong with DRM really. Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpDr7jexoDDt.pgp Description: PGP signature
Re: [arch-general] rsync patches
On Sun, Jan 04, 2015 at 03:34:17PM -0500, Ido Rosen wrote: > Hi, > I'd like to add --time-limit / --stop-at added to ArchLinux's rsync > since it's available in some other distributions. (This patch is > distributed from the same source as rsync itself, just in a different > tarball called rsync-patches, along with a bunch of other patches for > optional functionality that rsync can support but that isn't built > into the core rsync by default.) Below is an updated PKGBUILD for > rsync that adds time-limit support. There are several other patches > in rsync-patches that could be useful, but this is the one that most > affects me. > > Pierre did not respond to my email back in October, so Pierre, if you > are monitoring this list, see the attached PKGBUILD, it's a trivial > addition. I hope you'll make the change. :-) The ML isn't a proper place to request features and report bugs. And I couldn't find any related feature-request in the flyspray... Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgp5IRy5nZB_E.pgp Description: PGP signature
Re: [arch-general] gpg source validation for kernel.org style signatures
On Mon, Jan 05, 2015 at 10:16:10AM +0100, Christian Hesse wrote:
> I do not think we need HTTPS, though it does not hurt. If anybody tries to
> fool us with man-in-the-middle via HTTP we should detect that just fine with
> broken signatures (given signatures are provided...).
>
> Appending .sign may help as well. In fact for an example file archive.tar.xz
> we may want to check for {${FILE},${FILE%.(xz|bz2|gz)}}.{asc,sig,sign}
>
> $ export FILE=archive.tar.xz
> $ echo {${FILE},${FILE%.(xz|bz2|gz)}}.{asc,sig,sign}
> archive.tar.xz.asc
> archive.tar.xz.sig
> archive.tar.xz.sign
> archive.tar.asc
> archive.tar.sig
> archive.tar.sign
Does makepkg(8) know how to check sigs of .tar files as opposed to .tar.xz?
Cheers,
--
Leonid Isaev
GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4
C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
pgpOi4jUPre_t.pgp
Description: PGP signature
Re: [arch-general] gpg source validation for kernel.org style signatures
On Mon, Jan 05, 2015 at 04:09:50AM -0500, Daniel Micay wrote: > On 04/01/15 04:05 PM, Christian Hesse wrote: > > Hello everybody, > > > > pacman 4.2.0 gained support for verifying source tarballs with kernel.org > > style signature. Some (even essential) packages could benefit from that, > > linux and git come to mind. > > > > How to handle this? Report a bug for every package? Provide a list here? > > I would create a wiki page with the list and then see if you can find a > developer interested in mass-adding the missing signatures. I'd be > interested in helping with it for [community], but you'll likely be able > to do it yourself soon ;). In the TODO list mentioned in this thread, community/exim is absent, even though its releases are signed (see e.g. this announcement https://lists.exim.org/lurker/message/20140811.135006.dc48cddf.en.html ). Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpSHvRrHEXbL.pgp Description: PGP signature
Re: [arch-general] Standard group for "hardware user"?
On Mon, Jan 05, 2015 at 07:12:41PM +, Neale Pickett wrote: > I run mdev instead of systemd-udev and was just alerted to the deprecation > of all the groups I'd been using. Looking at the filesystem package, it > seems that most of them are still present, but I presume they'll go away > eventually. In general... The groups you are talking about (i.e. optical, etc.) are arbitrary to begin with, so there is no strict requirement for having them. On a (current) Arch system your user doesn't need to be in any of these groups, so you can manually delete them. The reason is, as you said, that logind grants device access to local users. Of course, this logic won't work if you'd like to e.g. play audio over ssh (you'll have to be a member of audio). Regarding the "standard" group list, I'd do the following: (1) Look at /usr/lib/sysuser.d/*. This is the systemd way (tm) of defining "standard" groups. The filesystem .install script follows this convention, AFAIK. So, these groups are unlikely to be deprecated in Arch, unless they are also deprecated in systemd (which might happen on a whim of course). (2) Clone Arch SVN repos and grep the .install scripts for udev rules that set device permissions to the above groups. I don't think there will be many (lvm2 and device-mapper come to mind). If in (2) no packages come up, then just ignore Arch default groups (in the filesystem package). You already run a non-standard udev (mdev), so you'll have to make sure that the device nodes are created with a correct u+g permissions (via some rules). These rules will define your "standard" group list. Otherwise, stick with systemd groups. HTH, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpAiJowBT0Oj.pgp Description: PGP signature
Re: [arch-general] Standard group for "hardware user"?
On Mon, Jan 05, 2015 at 09:59:51PM +, Neale Pickett wrote: > This is very helpful. Thank you! If you go with your own group list, check configs of your daemons to see which groups they expect. Some (e.g. dnsmasq) will call useradd and groupadd in their .install files. But syslog-ng, for example, by default creates log files 640 root:log... Also, I just wonder, do you have systemd installed at all? Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpjpGJdxHCVA.pgp Description: PGP signature
Re: [arch-general] What's the holdup on Linux 3.18?
On Thu, Jan 08, 2015 at 01:51:36PM +, Mauro Santos wrote: > On 08-01-2015 00:00, Mark Lee wrote: > > Salutations, > > > > I was wondering what's the holdup on Linux 3.18. It's been in testing > > since 12/11/2014. > > > I suppose the reason is this: > https://bugs.archlinux.org/task/43143?string=43143 Strange, is that an issue specific to Intel atom GPUs? I have not seen any problems on a dual Intel (Ci7 4800) and AMD graphics machine. Anyway, it is easy enough to just download and install the linux package directly, even if [testing] is disabled. BTW, to those updating, one notable (at least from my perspective) change with 3.18.y is the new module br_netfilter responsible for filtering traffic coming through a bridge. This module is not loaded automatically, so no firewall is enabled by default in bridges. Here is a dmesg snippet: --- kernel: [ 23.690774] bridge: automatic filtering via arp/ip/ip6tables has been deprecated. Update your scripts to load br_netfilter if you need this. --- Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgp2gGJEZSUlF.pgp Description: PGP signature
Re: [arch-general] What's the holdup on Linux 3.18?
On Thu, Jan 08, 2015 at 07:18:25PM +, Mauro Santos wrote: > On 08-01-2015 18:57, Leonid Isaev wrote: > > > > BTW, to those updating, one notable (at least from my perspective) change > > with > > 3.18.y is the new module br_netfilter responsible for filtering traffic > > coming > > through a bridge. This module is not loaded automatically, so no firewall is > > enabled by default in bridges. Here is a dmesg snippet: > > --- > > kernel: [ 23.690774] bridge: automatic filtering via arp/ip/ip6tables has > > been deprecated. Update your scripts to load br_netfilter if you need this. > > --- > > I'm not sure I'm reading it right and a quick google search doesn't turn > up much besides this[1]. Does this apply to filtering via iptables > (traffic from/to localhost to/from machines on the bridge) or more > specifically to ebtables (filter traffic between machines on the bridge)? > > [1] http://ebtables.netfilter.org/documentation/bridge-nf.html The former. It applies to filtering traffic passing through the bridge. If the module is loaded and /proc/sys/net/bridge/bridge-nf-* == 1 then you should be able to manipulate traffic _inside_ the bridge using iptables FORWARD chain. If the module is not loaded, or the above files contain 0, then the bridge acts as a "dumb" switch. So, you can use the FORWARD chain to forward packets _between_ the bridge and some other interface. The warning is because with linux < 3.18, bridge-netfilter was enabled by default, so you'd need a service that nullifies bridge-nf-*. Now, the module is not loaded by default, so the files are not there, and the existing service will fail. Basically there is no need to do what is suggested in [1] and [2]. (Note, that the sysctl was never the right approach to begin with, no idea who put it in thw wiki). [1] https://wiki.archlinux.org/index.php/QEMU#Creating_bridge_manually [2] https://bugzilla.redhat.com/show_bug.cgi?id=512206 Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpI7fwvliM_d.pgp Description: PGP signature
Re: [arch-general] syslog-ng + systemd-journald = no logs for syslog-ng
TL:DR: Syslog-ng in [extra] is kind of broken, so you'll need to a few steps to
get it to work in your environment.
On Sun, Feb 15, 2015 at 10:37:22AM +0100, ephae...@gmx.net wrote:
> ## vanilla /etc/syslog-ng/syslog-ng.conf
> # grep -v '^#' /etc/systemd/journald.conf
>
> [Journal]
> ForwardToSyslog=no
1. Set this to "yes".
2. Replace the stock syslog-ng.service with this:
--
$ cat /etc/systemd/system/syslog-ng.service
[Unit]
Description=System Logger Daemon
Documentation=man:syslog-ng(8)
Requires=syslog.socket
[Service]
ExecStart=/usr/bin/syslog-ng -F
ExecReload=/usr/bin/kill -HUP $MAINPID
StandardOutput=null
[Install]
WantedBy=multi-user.target
Alias=syslog.service
--
3. Fix the src{} in syslog-ng.conf:
--
source src {
#system();
unix-dgram("/run/systemd/journal/syslog");
internal();
file("/proc/kmsg");
};
--
4. Reenable syslog-ng.service and restart syslog.
Explanation:
Syslog indeed imports data from journald, but _only_ if journald stores the
logs (I guess that syslog-ng reads logs from the journald file on-disk). If you
don't want journald storage, you'll have to use the "old" way by making systemd
forward logs to syslog. The stock syslog-ng.service file is broken because it
doesn't pull in syslog.socket.
And, no, I haven't filed any bugreports, so go ahead if you feel like it. But I
personally recommend simply repackaging syslog-ng without systemd support...
HTH,
--
Leonid Isaev
GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4
C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
pgp4hiN4rQhvj.pgp
Description: PGP signature
Re: [arch-general] debug package repositories again
On Wed, Aug 12, 2015 at 12:36:22PM -0700, Joe Julian wrote: > It's been hashed and rehashed, but I need to bring this up again. Every > other popular distro has a way of debugging without completely rebuilding a > package, saving countless combined hours. > > Why can't we just have a way of installing the symbols? Not enough manpower... > Allan has already added the features necessary to make this possible. > > Why is this so hard? What can I do to help make this a reality? Well, there has to be a separate [debug] repo which (most importantly) must be kept in-sync with the main ones, or more packages in current repos. Then, someone has to actually build those packages. I would personally prefer that most packages come with debugging enabled by default. Surely, there will be a performance cost, but speed is not crucial in most cases. Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
Re: [arch-general] debug package repositories again
On Thu, Aug 13, 2015 at 03:11:58PM +0200, Evan Penner wrote: > >> I would personally prefer that most packages come with debugging enabled > >> by > >> default. Surely, there will be a performance cost, but speed is not > >> crucial in > >> most cases. > >> > >> Cheers, > >> > > > > There's no performance impact, just disk space and bandwidth. > > > > Bandwidth is probably the main problem, although anyone who wants to debug > will probably be fine with that. I think you guys misunderstood me. The biggest problem IMHO with building debug versions locally is not compiling itself, but setting up the environment. So, I meant that packages come with debugging enabled (compiled with gcc -O0 -g and perhaps ./configure options). This way, there will be not many new packages. Of course, this is not a good idea for things like FF/Gnome/KDE because of a slow-down, but a performance penalty for smaller programs like vim, links, XFCE4 etc. will not be noticeable (at least I don't see any for a self-compiled xfce4 desktop on a single-core Intel Atom based netbook). Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
Re: [arch-general] debug package repositories again
On Thu, Aug 13, 2015 at 10:09:00AM -0700, Joe Julian wrote: > >>Bandwidth is probably the main problem, although anyone who wants to debug > >>will probably be fine with that. > >I think you guys misunderstood me. The biggest problem IMHO with building > >debug > >versions locally is not compiling itself, but setting up the environment. > >So, I > >meant that packages come with debugging enabled (compiled with gcc -O0 -g and > >perhaps ./configure options). This way, there will be not many new packages. > > No, the biggest problem with building debug versions locally is that it > takes hours of developer time multiplied by every bug found. Why are we > wasting such a limited resource when it's so easy not to? Life is finite. That's just pure theory. In practice, the compilation itself is a minor inconvenience, unless you are talking about Gnome/KDE. But debugging those is hopeless anyway :) As a developer, you'll spend most time understanding the changes (looking at the code), not compiling. > >Of course, this is not a good idea for things like FF/Gnome/KDE because of a > >slow-down, but a performance penalty for smaller programs like vim, links, > >XFCE4 etc. will not be noticeable (at least I don't see any for a > >self-compiled > >xfce4 desktop on a single-core Intel Atom based netbook). > > > >Cheers, > > What is this slow-down you keep talking about? I'm not asking to do away > with optimization, just give us a way to get the debug symbols without > rebuilding. The debug symbols are located in totally different sections from > the code/data sections. You can check it with objdump: I was under the impression that with C, -On (n > 0) is not recommended with -g. Now, I don't know how much -O2 (for example) speeds things up compared to -O1 etc, but probably not much on small applications. Granted, I think any compiler-level optimization is overrated, and I never really saw any measurable effect of it. But I use Fortran (not C) for all my projects. Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
Re: [arch-general] Any ETA on the Tex Live 2015 update?
> I'm also curious about this. It seems like the maintainer hasn't been > active for the past 5 months.[1] > What is the normal course of action in such a case? For instance, how could > I contact the maintainer? TeXLive is not a critical package, so what's the rush updating it? If you really want to see an updated version, open a bugreport and attach there a patched PKGBUILD. And of course, you can always build the latest version locally (just clone the svn trunk and run makepkg)... Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
Re: [arch-general] Any ETA on the Tex Live 2015 update?
On Mon, Aug 24, 2015 at 12:15:32PM -0500, Doug Newgard wrote: > On Mon, 24 Aug 2015 17:00:18 + > Leonid Isaev wrote: > > > > I'm also curious about this. It seems like the maintainer hasn't been > > > active for the past 5 months.[1] > > > What is the normal course of action in such a case? For instance, how > > > could > > > I contact the maintainer? > > > > TeXLive is not a critical package, so what's the rush updating it? If you > > really want to see an updated version, open a bugreport and attach there a > > patched PKGBUILD. And of course, you can always build the latest version > > locally (just clone the svn trunk and run makepkg)... > > > > Cheers, > > Please do not file a bug report because a package is outdated. This is the #1 > rule of the bugtracker. Sorry, I meant feature request. Of course, opening tickets just to say that a package X is out-of-date is silly. But if the project is complex (like texlive-*) then bumping it may not be a simple issue. So if I happen to go through this exercise before the maintainer, how am supposed to communicate the working PKGBUILD, in an open fashion? A ML would be best of course, but arch-general isn't a place for this... Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
[arch-general] iptutils 20150815.1b5d03a-2 and ipv4-only system
Hi, I noticed that ping in [testing]/iputils does not work on systems with disabled IPv6 stack. For example (as root): -- # ping archlinux.org ping: socket: Operation not permitted (raw socket required by specified options). # cat /proc/cmdline BOOT_IMAGE=../vmlinuz-linux ... ipv6.disable=1 ... # pacman -Qo ping /usr/bin/ping is owned by iputils 20150815.1b5d03a-2 # getcap /usr/bin/ping /usr/bin/ping = cap_net_raw+ep -- I tried playing with cmdline options, without any success. ping from [core]/iputils 20140519.fad11dc-1 does work. Is this a bug or a feature, and does anyone know how to make ping work again? Thanks, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
Re: [arch-general] iptutils 20150815.1b5d03a-2 and ipv4-only system
[replying to both emails] On Wed, Sep 09, 2015 at 12:11:29PM +0200, Joakim Hernberg wrote: > On Tue, 8 Sep 2015 14:14:31 -0600 > Leonid Isaev wrote: > > > I tried playing with cmdline options, without any success. ping from > > [core]/iputils 20140519.fad11dc-1 does work. Is this a bug or a > > feature, and does anyone know how to make ping work again? > > You could create an ip6table firewall that just drops most > things and leave ipv6 enabled in the kernel. All networks on which I have Arch machines are IPv4-only. So I don't need IPv6... > > -- > >Joakim On Wed, Sep 09, 2015 at 01:49:34PM +0200, Jens Adam wrote: > Tue, 8 Sep 2015 14:14:31 -0600 > Leonid Isaev : > > > Is this a bug or a feature, and does anyone know how to make ping work > > again? > > Have you tried 'ping -4'? > Yes, it's undocumented. Yep :( -- # ping -4 google.com ping: socket: Operation not permitted (raw socket required by specified options). # ping -N ipv4 google.com ping: socket: Operation not permitted (raw socket required by specified options). -- Thanks, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
Re: [arch-general] iptutils 20150815.1b5d03a-2 and ipv4-only system
On Wed, Sep 09, 2015 at 08:04:37PM +0200, Joakim Hernberg wrote: > afaik > disabling ipv6 with a kernel boot flag is not recommended and one can > expect breakage... Why? Where is it written? Sure, I don't expect ipv6-specific software to work on my system but the ipv4 stack is fully functional. Thanks, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
Re: [arch-general] Thunar sftp connection not working - access denied
On Sat, Oct 10, 2015 at 02:05:38AM +0200, Friedrich Strohmaier wrote: > Hi Folks, > > since some time I cannot get thunar connect my remote servers folders via > sftp. > > Error dialog: > Failed to open "/my/remote/path on my.server" > access denied > > ssh access works as expected. > > I feel like it stopped working after I got this arch announce: > https://www.archlinux.org/news/d-bus-now-launches-user-buses/ So, does sftp work from the command line? Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
Re: [arch-general] [arch-announce] Xorg 1.18.0 enters [testing]
On Fri, Nov 13, 2015 at 01:01:09PM -, Arch Linux: Recent news updates: Laurent Carlier wrote: > Xorg 1.18.0 is entering [testing] with the following changes: > > * You can now choose between `xf86-input-evdev` and `xf86-input-libinput`. > > * `xf86-input-aiptek` will not be updated and will be removed when > xorg-1.18.0 > is moved to [extra] > > Caveat: > > NVIDIA drivers are not yet compatible with 1.18.0. You can block the upgrade > by > appending --ignoregroup=xorg to the pacman command or adding 'xorg' to > IgnoreGroup in pacman.conf > > URL: https://www.archlinux.org/news/xorg-1180-enters-testing/ Hmm, on my machine Xorg now runs as root, and I had to create /etc/X11/Xwrapper.config to enfoce the old behavior of dropping suid privs... Has anyone else noticed this? Thanks, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
Re: [arch-general] Policy about packages and file capabilities
On Mon, Nov 16, 2015 at 07:51:30PM +0100, Damjan Georgievski wrote: > What's the policy about capabilities for executables in Arch packages? I _guess_ that capabilities are used to avoid SUID binaries when this is secure. > I'm asking since in my setup I'm running wpa_supplicant as the > 'nobody' user, but I let it keep the NET_ADMIN and NET_RAW > capabilities (excerpt from the .service file): Read the caveat here: https://w1.fi/cgit/hostap/plain/wpa_supplicant/README . Basically, you'll need a special user/group for executing /usr/bin/wpa_supplicant. In general, why is this necessary? What kind of attack (besides DoS) is possible against wpa_supplicant? Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
Re: [arch-general] Policy about packages and file capabilities
On Mon, Nov 16, 2015 at 09:00:28PM +0100, Damjan Georgievski wrote: > >> What's the policy about capabilities for executables in Arch packages? > > > > I _guess_ that capabilities are used to avoid SUID binaries when this is > > secure. > > well, also, unless you set capabilities on the executable a process > can't have capabilities when a non-root process execs the executable Sure, that's what is done with the ping(8) binary. > >> I'm asking since in my setup I'm running wpa_supplicant as the > >> 'nobody' user, but I let it keep the NET_ADMIN and NET_RAW > >> capabilities (excerpt from the .service file): > > > > Read the caveat here: https://w1.fi/cgit/hostap/plain/wpa_supplicant/README > > . > > Basically, you'll need a special user/group for executing > > /usr/bin/wpa_supplicant. > > right, I think that too would need to be done in a proper package. > I'd rather make it 750, and root/wpa_supplicant Which means that the filesystem package should get modified? > > > In general, why is this necessary? What kind of attack (besides DoS) is > > possible against wpa_supplicant? > > there have been buffer overflows etc. in wpa supplicant, not good for > a root process. > https://www.google.com/search?q=wpa_supplicant+CVE&ie=utf-8&oe=utf-8 But those CVEs are mostly denial of service... right? -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
Re: [arch-general] ssd trim using fstrim.service and fstrim.timer
On Sun, Dec 27, 2015 at 09:45:27PM -0500, Francis Gerund wrote: > Per the Arch wiki SSD page, I just enabled sysctl fstrim.timer, and then > rebooted. I did not "enable" fstab.service. Now fstrim.timer is loaded, > and active (but "waiting") and fstrim.service is loaded, but inactive. And > the time stamp file the wiki mentions has a "0" size. In /var/lib/systemd/timers? They all have zero size, it's their timestamp what matters. > So, do I have to wait (A WEEK!) to see if it works, or can I somehow now > run fstrim.service manually to at least get it done once? fstrim.service most likely ran on-boot, silently, so you haven't noticed. If you use systemd-journal, check it, otherwise just start fstrim.service w/o enabling it (or run its ExecStart cmdline). > Note: I could just add "discard" to /etc/fstab, but wouldn't that wear out > the SSD faster than periodic trimming? I don't know precise numbers, but IME none of those made a difference performace-wise. I'd say if SSD wear is a problem (i.e. if you estimate it within expected usage time of the device), just switch to a HDD. HTH, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
Re: [arch-general] [OT?] Which is most future-proof desktop environment?
On Wed, Dec 30, 2015 at 11:57:48AM +0100, Ralf Mardorf wrote:
> Xfce4
>
> After an update e.g. a small window title bar with a clean design,
> became a fat thing with a Microsoft appeal.
Wrong. It's not xfwm4, but the default gtk3 theme. Just use a gtk2 xfwm4 theme
and be happy :) Or better yet, recompile libxfce4ui w/o gtk3 support.
> The long and the short of it, if you want to decide how your
> environment should work, what you need and what not, then better do not
> use ad DE such as GNOME, KDE, Xfce4 or similar, instead use a WM
> such as openbox, jwm or similar.
A DE is a vague concept because it includes many non-essential (IMHO) "apps"
like browser, file manager etc. For instance, is GNOME epiphany in any way
superior to FF or Chromium (besides "better integration")? Or how does a
DE-specific calculator better than bc(1)?
For apples-to-apples comparison, I'd only focus on WMs because this is a
component you interact with the most. Bigger DEs have failry sophisticated
compositing WMs (xfwm4, kwin, whatever metacity is called these days) with hw
acceleration etc. Compositing does not imply eyecandy, it's just a better use
of system resources (for instance by exploiting GPU).
On the contrary, things like {open,flux}box and tiling WMs (i3, jwm) still use
a design from '90s. And from olden days of Win98 we remember what it leads to.
Cheers,
--
Leonid Isaev
GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4
C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
Re: [arch-general] Firefox without signature checking
On Sat, Jan 02, 2016 at 02:06:05PM -0800, Kyle Terrien wrote: > Thank you! I was tempted to reopen it, but it looks like the general > consensus is that an AUR package will be submitted. You can only request to reopen... > It looks like sticking to upstream trumps user-centric in this case. > (Although I guess building from AUR is a fair substitute for > user-centric.) Yes, that's what the SVN repo is for: if you don't like the official release (= the one in binary repos), just clone && rebuild the thing yourself. As a bonus, you can get rid of unnecessary deps. > It's a real bummer that a bunch of users (myself included) will be > forced to compile Firefox on each release. I really hope we can > eventually get an abrowser or firefox-nobranding (or maybe even > palemoon) into the repos. Compiling FF doesn't take long if you disable PGO in PKGBUILD. > How can we nominate a package into community or extra? The package will have to get enough votes in the AUR and someone should want to maintain it in the repo. > (And if you are fed-up with Mozilla's walled-garden policy like I am, I > suggest trying out Pale Moon [0].) ... which you need to build yourself anyway. Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
Re: [arch-general] Firefox without signature checking
On Sat, Jan 02, 2016 at 11:25:12PM +0100, Niels Kobschaetzki wrote: > What about an AUR-package with a pre-compiled binary? Sure I have to > trust the maintainer. No, this is a recipe for spreading malware. Also, have you seen the size of said binary? > But I also have to with a source-package since I > won't check the sources with each release ;) Which is plain stupid. Best, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
Re: [arch-general] Firefox without signature checking
On Sat, Jan 02, 2016 at 04:50:06PM -0600, Doug Newgard wrote: > On Sat, 2 Jan 2016 15:35:01 -0700 > Leonid Isaev wrote: > > > On Sat, Jan 02, 2016 at 02:06:05PM -0800, Kyle Terrien wrote: > > > Thank you! I was tempted to reopen it, but it looks like the general > > > consensus is that an AUR package will be submitted. > > > > You can only request to reopen... > > And that request would be denied unless you can bring new info to the table. > So far, I haven't seen any. Me? I fully support closing that bugreport. And moreover, I am not affected by the discussed issue, as I run FF beta... Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
Re: [arch-general] Firefox without signature checking
On Sun, Jan 03, 2016 at 12:18:36AM +0100, Magnus Therning wrote: > How is that stupid? Do you check the sources with each release? *How* > do you perform those checks? OK, fact #0 - I only use software whose upstream I trust. Having said that, I usually pull md5sums and sha*sums in the PKGBUILD, all from different sources (upstream, Debian, Gentoo, etc.), if the src is not upstream-signed. FF releases _are_ signed (I don't know why the PKGBUILD in [extra] doesn't check that), so just have the Mozilla signing key (currently 0x61B7B526D98F0353) in your keychain. If you trust random people in the AUR and never inspect their PKGUILDs, or even worse, use their binaries, you deserve to be rooted. Best, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
Re: [arch-general] Firefox without signature checking
On Sat, Jan 02, 2016 at 05:34:51PM -0600, Doug Newgard wrote: > Just expanding on your point. Ah, OK, sorry :) Also, perhaps one should note that "walled garden" discussions (albeit justified) belong at Mozilla's bug tracker, not Arch's. Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
Re: [arch-general] Firefox without signature checking
On Sat, Jan 02, 2016 at 03:26:59PM -0800, Kyle Terrien wrote: > On the other hand, I fully understand why we would want to follow > upstream--less work for packaging and testing, as well as official > sanctioning via branding. It's neither. Mozilla advertises certain level of default security. If Arch is to reduce that, I think the package will need to be renamed, just not to mislead unsuspecting users. The expressed concerns have nothing to do with the branding or maintenance. Also, if you have specific concerns about the signing procedure, deal with people @Mozilla. (I don't really care because I don't use any addons.) Best, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
