Re: [arch-general] Any objections to asking vim to fix PKGBUILD syntax highlighting?

[Ismael Bouya]

(Tue, Mar 05, 2019 at 06:26:45AM -0500) james harvey via arch-general :
> I'd like to post the following issue at: https://github.com/vim/vim/issues/new
> 
> Wanted to see if there were any objections from staff, like if even
> though the error highlighting is technically wrong, if it's desired to
> be left as-is to discourage 'pkgname' being a single element array or
> 'SKIP' usage when inappropriate, etc.

Hi James, I think you’re targetting the wrong project:
immae@immae ~ $ pacman -Qo /usr/share/vim/vimfiles/syntax/PKGBUILD.vim
/usr/share/vim/vimfiles/syntax/PKGBUILD.vim is owned by pacman-contrib 1.1.0-1

PKGBUILD probably doesn’t exist in vim’s project ;)
-- 
Ismael


signature.asc
Description: PGP signature

Re: [arch-general] X logs me out from tty on close

[Ismael Bouya]

> Hello, thanks for your reply, but I don't know how to try that neither,
> still looking into it. Also this is a fresh install and almost all files
> are default. /etc/X11/xinit/xinitrc is auto-generated at install with some
> xterms and an xclock, and /etc/X11/xorg.conf was non-existent (later
> generated with nvidia-xconfig to try with nvidia-xrun). Another observation
> is even when x fails to initialize or force closed by pkill, same thing
> happens.

I think you just proved my hypothesis wrong :)
If I understand correctly, your environment is a single terminal + a clock?
if so, then exiting the terminal should bring you back to the console.

Other questions that could help investigate:
- How do you start the startx command?
- Do you have maybe an .xinitrc in your home?
- startx is normally just a wrapper around xinit, could you maybe look
  at your process list and see what arguments are given to xinit? That
  could help investigate.
  xinit itself takes arguments of the form
xinit [client] -- [server]
  where server is the part to start the X11 server and client is the
  script to run as user. This is the part that determines what is
  started (not /etc/X11/xinit/xinitrc, which is normally given by startx
  as a fallback)
-- 
Ismael


signature.asc
Description: PGP signature

Re: [arch-general] X logs me out from tty on close

[Ismael Bouya]

(Thu, Jan 10, 2019 at 12:16:20PM +0300) Ali Emre Gülcü via arch-general :
> Hello everyone,
> I had a rather interesting problem recently. I dont have any display
> manager and I open desktop environment from tty when needed. Previously
> when I logged out from Xfce or closed down X server, it would put me back
> on my tty session. Now when I do the same, it also logs me out from tty and
> I must login again. Is this the expected behaviour after some xorg or
> kernel update? Or did I mess up something? I tried with both `startx` and
> `startxfce4`. And to be sure that this is not an driver related problem, I
> also tried with `nvidia-xrun`, same results.

Hi Ali,
To me it sounds rather like your session exists now with a killall
instead of  before.

Did you change something related to that recently? You could try to
check that hypothesis (I don’t know exactly how, maybe running some
additional forked process in your initrc and see if it gets killed when
you exit?).

-- 
Ismael


signature.asc
Description: PGP signature

Re: [arch-general] bind/named dying after 24-48 hrs. "assertion failure"?

[Ismael Bouya]

>   Has anyone else encountered a bind 9.13.4-1/named daemon dying with
> "assertion failure" in the past week. I have encountered the problem twice.
> When named dies, status reports: (...)

Hey there,
It happened to me once, with the exact same symptoms, but I took it as a
random failure. Now that you mention it too, maybe there is something to
look at.

It happened for me after the bind upgrade (9.13.3-3 -> 9.13.4-1)

>   I don't know if this is somehow related to the timers and keys that may be
> timing out after some period of time. If no one else has seen this, I'll keep
> watching, but if anybody has any ideas, I'd welcome your thoughts.

I have no specific setup for keys/timers

Kind regards,
-- 
Ismael


signature.asc
Description: PGP signature

Re: [arch-general] Unbound

[Ismael Bouya]

Hey there,

> Find changed configurations:
> 
>   sudo find /etc -type f -regextype egrep -regex '.*(pacnew|pacsave)'
> 
> Diff them (individually):
> 
>   sudo vimdiff /path/to/original /path/to/original.pacnew

Note that pacdiff (from pacman-contrib package) does that in a more
"friendly" manner.

Kind regards,
-- 
Ismael


signature.asc
Description: PGP signature

Re: [arch-general] How to upgrade a postgresql database?

[Ismael Bouya]

(Fri, Aug 17, 2018 at 04:11:45PM +0200) Peter Nabbefeld :
> Am 17.08.18 um 16:05 schrieb Ismael Bouya:
> > Hi Peter,
> > What version are you upgrading from? Starting at version 10, you don’t
> > need any particular operation to upgrade minor version (10.X -> 10.Y),
> > that’s why the old binaries are "stuck" at 9.6.
> Current version is 9.6, updated version is 10.5

Then you probably missed that part in the wiki page:
---
a postgresql-old-upgrade package is available that will always run one
major version behind the real PostgreSQL package. This can be installed
side-by-side with the new version of PostgreSQL.
---

Upgrading your system (after shutting down postgresql) and installing
postgresql-old-upgrade should give you /opt/pgsql-9.6/, your current
psql version, and /usr/bin/psql, your target version (10.6). From there,
following the wiki should permit you to upgrade the data to the target
version.
-- 
Ismael


signature.asc
Description: PGP signature

Re: [arch-general] How to upgrade a postgresql database?

[Ismael Bouya]

Hi Peter,
What version are you upgrading from? Starting at version 10, you don’t
need any particular operation to upgrade minor version (10.X -> 10.Y),
that’s why the old binaries are "stuck" at 9.6.
-- 
Ismael


signature.asc
Description: PGP signature

Re: [arch-general] ClamAV Flagging systemd package

[Ismael Bouya]

Hi Giovanni,

> Most likely infected on your system, as the binary package in
> archive.archlinux.org seems to be clear:
> 
> clamscan systemd-238.51-1-x86_64.pkg.tar.xz
> 
> 
> 
> systemd-238.51-1-x86_64.pkg.tar.xz: OK

You’re not comparing the same file.

I confirm the alert for my own package file taken from a brand new
server (so most likely not infected)

This is probably a false positive though.

Kind regards,
-- 
Ismael


signature.asc
Description: PGP signature

Re: [arch-general] systemd --user enable: Failed to connect to bus: No such file or directory

[Ismael Bouya]

> systemctl --user status has the same error. How do I start dbus for the
> second user? systemctl enable --user dbus fails due the same error, and
> system's dbus is running.

Good,

Each user + the system has his own dbus. Normally, you should have
dbus.service and dbus.socket units somewhere (/usr/lib/systemd/user
and/or /etc/systemd/user and/or .config/systemd/user)

If it works correctly for one of the users, then probably
/usr/lib/systemd/user and /etc/systemd/user are fine, and there is an
override which breaks the things in .config/systemd/user/dbus.*

Note: If the non-working user is an "old" one, it may be explained by
the fact that those unit files are quite "recent", so probably there is
an history there.

Hope it helps to solve your problem
-- 
Ismael


signature.asc
Description: PGP signature

Re: [arch-general] systemd --user enable: Failed to connect to bus: No such file or directory

[Ismael Bouya]

Hi Bjoern,

> I'm trying to create a systemd timer for a user to run duply daily. For
> one user the enabled worked fine, but another one:
> 
> systemctl --user enable backup.timer
> Failed to connect to bus: No such file or directory
> 
> I have no clue why this happens, systemctl daemon-reload (also with
> --user) did not fix it. I found a similar issue in the forums, but the
> solution was to "ln -s" the timer and than rebooting. But I don't think
> this would be the "correct" solution because "systemctl --user enable"
> should also work.

The two clues I have according to your error are
- Is .config/systemd/user created? (Maybe it has to be created manually)
- Does the second user have dbus started correctly? (for instance, does 
  "systemctl --user status" work as intended for that user?) Maybe the
  second user has a non-working dbus service, or maybe it’s just an
  environment variable problem (if I remember correctly, XDG_RUNTIME_DIR
  is the variable that should be set correctly to something like
  /run/user/)

Kind regards,
-- 
Ismael


signature.asc
Description: PGP signature

Re: [arch-general] What files are tipically in /usr/local/share?

[Ismael Bouya]

hello,

> But this has me wondering if there was something more important which
> resides there.
> Perhaps something generated by an application or script.

manually installed ca certificates? programs installed with make
install? if programs in /usr/local/bin work correctly then there was
nothing important :)

for distribution packages,
you may check pacman -Qo /usr/local or /usr/local/share, but I think the
list is almost empty
-- 
Ismael


signature.asc
Description: PGP signature

Re: [arch-general] php php71 in conflict

[Ismael Bouya]

(Wed, Jan 10, 2018 at 11:24:47AM -0500) Eli Schwartz via arch-general :
> On 01/10/2018 10:12 AM, Ismael Bouya wrote:
> > Hello,
> > I wasn’t aware that php71 was in community, thanks for pointing it out.
> > However, the php package provides php-ldap, which php71 doesn’t (at
> > least not explicitly). Shouldn’t it mention that too? Otherwise it
> > becomes harder to replace php with php71 when we have php webapps that
> > require php-ldap (probably the case of phpldapadmin too?)
> 
> That definitely seems like an inconsistency, please open a feature
> request against php71 to provide php71-ldap=$pkgver and php-ldap=$pkgver.

Done:
https://bugs.archlinux.org/task/57037
-- 
Ismael


signature.asc
Description: PGP signature

Re: [arch-general] php php71 in conflict

[Ismael Bouya]

Hello,
I wasn’t aware that php71 was in community, thanks for pointing it out.
However, the php package provides php-ldap, which php71 doesn’t (at
least not explicitly). Shouldn’t it mention that too? Otherwise it
becomes harder to replace php with php71 when we have php webapps that
require php-ldap (probably the case of phpldapadmin too?)

Kind regards,
-- 
Ismael


signature.asc
Description: PGP signature

Re: [arch-general] tmux/systemd: tmux user service exits on detach/logout

[Ismael Bouya]

(Mon, Sep 25, 2017 at 03:28:07PM +) Eli Schwartz :
> Bugreport opened on our tracker, so this fix may get backported. ;)
> 
> https://bugs.archlinux.org/task/55746

I didn’t know this was "possible", thanks for reporting it :)
-- 
Ismael


signature.asc
Description: PGP signature

Re: [arch-general] tmux/systemd: tmux user service exits on detach/logout

[Ismael Bouya]

> Well, I'm sad to tell you, that I'm experiencing the issues again with
> 234.11-9, but didn't with 234.11-8 or 234.11-6.
> 
> This is getting pretty random, untracable and annoying... :(
> Especially, as there is no "real change"[1] between the last pkgrels...

Thanks. I searched a little longer and found that:
https://github.com/tmux/tmux/issues/1001

So we can now cross fingers and wait until 2.6...

In the meantime, if you keep at least one session open all the time, the
problem is much less frequent (In my case, I have a mosh session open
all the time from my phone to the server, which kind of helps). Still
annoying, but less frequent.

Kind regards,
-- 
Ismael


signature.asc
Description: PGP signature

Re: [arch-general] tmux/systemd: tmux user service exits on detach/logout

[Ismael Bouya]

> as follow up on this (probably not so interesting thread for too many),
> I have tested systemd 234 successfully.
> The weechat instance within tmux (or tmux itself) still ends
> sporadically, but not the main tmux user session.
> So, in conclusion, whatever has been broken in systemd 233, was probably
> fixed again in 234.

Hey David and all,
I'm in 234.11-8 and I still have this issue. What did you end up with
during your tests?
I do have KillUserProcesses=no and lingering for my user (it was working
for ages without issues before this summer for me too), and made other
various tests among the ones you mention, but it seems like you have the
right combination.

Kind regards,
-- 
Ismael


signature.asc
Description: PGP signature

Re: [arch-general] pacman doesn't show download progress

[Ismael Bouya]

(Tue, Aug 15, 2017 at 02:05:44PM -0700) Moses Miller via arch-general :
> Can you explain in more detail what the problem is, and show actual and
> expected output?

Hello,
I have the same "problem" for a few weeks too.
Here is the output of pacman -Syu I got just now on two machines:
https://paste.ee/p/hqCTu
https://paste.ee/p/eLu01

In the first one, you see download progress on the packages.
In the second one you don't see them. Here you don't see them at all (probably
because there are only a few packages), but it happens that I only see a few of
them. The behavior is completely random, and on both machines: it's just luck
that I could get the two different examples today

The only line that differs between both machines in pacman.conf is IgnorePkg:
--
[options]
HoldPkg = pacman glibc
IgnorePkg   = (...)
Architecture = auto
Color
CheckSpace
SigLevel= Required DatabaseOptional
LocalFileSigLevel = Optional
[core]
Include = /etc/pacman.d/mirrorlist
[extra]
Include = /etc/pacman.d/mirrorlist
[community]
Include = /etc/pacman.d/mirrorlist
[multilib]
Include = /etc/pacman.d/mirrorlist


[NB: I "think" it's related to curl (didn't check if pacman uses it though)
since I have a similar experience once with that command in a non-related use.]

Hope it can help.
-- 
Ismael


signature.asc
Description: PGP signature

Re: [arch-general] Sébastien Luttringer and Tobias Powalowski

[Ismael Bouya]

(Sun, Jul 02, 2017 at 07:22:23PM -0400) Eli Schwartz via arch-general :
> Okay, this I am genuinely curious about.
> 
> In what circumstances can I have:
> - the systemd repository cloned over the git:// protocol
> - an annotated tag for systemd v233 signed by Lennart Poettering.
> - an annotated tag for systemd v232 signed by Lennart Poettering.
> - a man in the middle attack
> - `git verify-tag --raw v233` reports a GOODSIG with a VALIDSIG
>   ${fingerprint} that matches with Lennart's known GPG fingerprint as
>   recorded in validpgpkeys
> 
> And as a result, when I run the git command `git checkout
> refs/tags/v233`, I am tricked into getting v232 instead which contains a
> vulnerability.

Until there, it's exactly the topic of the presentation linked by
Nicohood

> Also, I wouldn't be alerted by the verbose printing of
> the systemd version which happens during the boot process, nor by
> $systemd_binary --version

Then you rely only on that last two things

-- 
Ismael


signature.asc
Description: PGP signature

Re: [arch-general] Sébastien Luttringer and Tobias Powalowski

[Ismael Bouya]

(Mon, Jul 03, 2017 at 01:06:04AM +0200) Morten Linderud :
> At this point we can't trust the trusted users to build and verify the
> correct packages, let alone maintaine a safe infrastructure to build
> packages. This is a slippery slope, and i really fucking hope this
> isn't a serious issue any devs or TUs are afraid of.

I didn’t imply that, but it’s easy to rely on the "gpg check" to skip
other checks.

I never faced the problem, but right out of my mind I don’t know how to
download a git project archive and check easily that I got the correct
tag.

-- 
Ismael


signature.asc
Description: PGP signature

Re: [arch-general] Sébastien Luttringer and Tobias Powalowski

[Ismael Bouya]

(Mon, Jul 03, 2017 at 12:29:44AM +0200) Morten Linderud :
> But HTTPS doesnt matter here. We have a trusted signer inn the PKGBUILD, 
> anyone can MITM for the good of their life.
> Unless they can fake the signature (Hint; they cant), or trick Lennart into 
> signing something he shouldnt (Hint; he
> wont), we don't have a case here. It doesn't really matter if its HTTP or 
> HTTPS.
> 
> You also didn't really reply about the threat model.

If I understand correctly what Nicohood meant,
what could happen is that version X of systemd (or anything else) has a
well known vulnerability, fixed in X+1. X+1 is packaged, so anyone
up to date thinks "good I'm safe now". But since a man in the middle can
force to download version X (signed by the systemd maintainer so
considered "secure"), he can force you to download that version when you
create the package and you'll think you have the safe version while
having the unsafe one.

If that happens to the packager in archlinux, then you poisoned all
archlinux users.

(but then, the md5sum will be wrong anyway?)
-- 
Ismael


signature.asc
Description: PGP signature

Re: [arch-general] MariaDB not starting

[Ismael Bouya]

Hello,

> 1) "systemctl status mariadb.service":
(...)
> Jan 27 13:04:10 tuchola mysqld[4574]: 2017-01-27 13:04:10 140214454369792
> [ERROR] Fatal error: Can't open and lock privilege tables: Table
> 'mysql.user' doesn't exist
(...)

I'm not ssure about what you tried, but your installation seems
incomplete.
Did you run the 
mysql_install_db --user=mysql --basedir=/usr --datadir=/var/lib/mysql
before starting it?

Did you follow the installation instructions there
https://wiki.archlinux.org/index.php/MySQL ?
If not, you should start there maybe :)

Kind regards,
-- 
Ismael


signature.asc
Description: PGP signature

Re: [arch-general] Opinions on PowerShell?

[Ismael Bouya]

(Fri, Aug 19, 2016 at 11:59:00AM +0200) Jeroen Mathon via arch-general :
> Will that shebang work correctly with powershell?

This is the os's job, not bash's or powershell's, to work correctly with
shebang. From the shell point of view a script is no different to a binary, as
long as it is executable.
If you try to source it, it's another problem of course.
-- 
Ismael


signature.asc
Description: Digital signature

Re: [arch-general] [arch-dev-public] signoffs are dead

[Ismael Bouya]

Hey there,
At some point I started to receive those "signoff" message on one of the list
I'm subscribed to. I searched on the wiki what that meant, but with no result. I
see that on https://wiki.archlinux.org/index.php/Official_repositories you
mention in one sentence what it is, but sorry it's not clear what I can do about
that. I also spend maybe half an hour trying to find that in my profile, with no
result either. I concluded that maybe it was something for only trusted users,
and it was just not my business.

Maybe the first step before considering the signoff "dead" would be to educate
people on how to do that? It might be obvious to the Trusted users on how
everything works. As far as I am concerned, I have no idea of the packaging
process apart from AUR. All the technical parts are now natural to me, but all
the "human" process is completely obscure.

Kind regards,

(Tue, Jun 28, 2016 at 07:28:10PM -0700) Kyle Terrien via arch-general :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> I am replying to arch-general because arch-dev-public is closed to most
> users.
> 
> On Tue, 28 Jun 2016 08:09:41 -1000
> Gaetan Bisson  wrote:
> > Dear all,
> > 
> > For a while now packages in [testing] have gotten little to no
> > signoffs and I've been moving mine to [core] after a week without
> > feedback. I suspect many of you have been doing this too. Here's the
> > signoff reports over the last ten days:
> > 
> > - June 19: 0 signoffs
> > - June 20: 6 from me, 4 from anthraxx
> > - June 21: 0
> > - June 22: 5 from me
> > - June 23: 2 from demize
> > - June 24: 1 from me
> > - June 25: 0
> > - June 26: 1 from me
> > - June 27: 3 from me, 1 from eworm
> > - June 28: 3 from heftig, 2 from arojas
> > 
> > So I've decided to shorten the wait in [testing] to 48 hours. Many
> > updates to [core] packages include security fixes and they have better
> > move sooner rather than later. We used to be able to gather enough
> > signoffs to move these within a day or two, and that's what I intend
> > to do with or without signoffs.
> > 
> > Any comment, and especially any other idea to fix this situation, is
> > welcome.
> > 
> > Cheers.
> 
> First, I am an Arch user (for 3 years now) not an Arch dev, and I
> realize I have no right to tell anyone how to run the distribution.
> What follows is just my personal recommendation based on working
> software QA professionally.
> 
> With that said, I think eliminating signoffs is a bad idea.
> 
> Signoffs ensure some form of quality control.  A signoff is an explicit
> approval from someone that the package is satisfactory to his/her
> standards.  A potential signee has a completely different perspective
> than the packager and a different way of verifying that the packager's
> package is correct.  This sort of approval process catches errors that
> would otherwise escape the packager's notice.  Simply waiting a period
> of time without hearing complaints is not equivalent to explicit
> approval from others.
> 
> I have personally experienced several breakages in the past several
> months--more than usual.  A few were big enough that simply running 'foo
> - --version' should have revealed a problem (i.e.  linking problems).  A
> signoff process would have very likely caught these problems.
> 
> IMHO, the correct thing to do is remind other developers of the signoff
> policy.  (And the above post to arch-dev-general certainly does just
> that.)  Encouraging another set of eyes to look at someone's work and
> say, "This looks good to me," is a very good thing and does wonders in
> terms of quality control.
> 
> If getting security fixes pushed out is a concern, then getting the
> security related fixes signed off should be prioritized.  (Maybe by
> putting in a flag that automatically triggers a mail to arch-dev-public)
> 
> Respectfully yours,
> - --Kyle Terrien
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
> 
> iQIcBAEBCAAGBQJXczI6AAoJEN5rMzXPJBsQASIP+gLGiQbQVrg/mNVDacXaHuEK
> 8H3QQz9amQMwgQXq8Mh17HWfbiQMQMWD48O9CBP+fUyWLVPOxs6g4H/aXFiIm4G+
> Qw6/vWfgQaGjY60nLJ7D8/NVq9PwXSPEYF1cA8/6D7JtuotwXxCFENiNR9Qki7Un
> 3QCXRI6Z/KKGcpBvpIsa++qDeZuXnSTy00ZJO5EFYxTi+AUBEyffHX/bS2IUCOkC
> tUWxtoVIix4buD32/tCnPz19wku9MylddYBzNuB1qCD1NG6XLsxmn8WiHGeoiy+E
> uFwjxPgDx0MaldNNJzubC2LQD/osdTDTTPwDf2M0c802FI+pHxlj/Dk9imz86NFA
> 9xPH8WJ1cfiVTue0BkRJXlR2eI0VIPSqAbpcDCfzCwYbrFuFoqwszpET03PtF/Y4
> 5tfZHLODiFpDc9Whu5o4ejzf4p/eMUN3xmwUp+8cguFcSmjBSPvYvRbgI8puiPRm
> Al5xYxnrmghEf9R5fIRUWoHlsGNNMrmd1MKquJ6i1+Dkf0pmUK4t58G3crWjFb7+
> laMUKYRmH+LwYhxvET562E8EM8QYYtow+PietZssC7ZhjGa1sG70FahQWCijmIj6
> TdpfCiNgmQ8AF4C4JXhzZvONtdYzUeNSgiv/FkA9T4n9Xje/ZCUhyM+inaqmA/5A
> ComaWc2SjeM8gTBfdPQa
> =E42/
> -END PGP SIGNATURE-

-- 
Ismael


signature.asc
Description: Digital signature

[arch-general] Apache (Roundcube) and /tmp

[Ismael Bouya]

Hi,
I tried to install roundcube (in community/), but it fails when it tries to
check if he can write in his temp dir, which is a symlink that points to
/tmp/roundcube and is rwx for http (and group http too).

I have the same problem if I try to put the symlink to /var/tmp/roundcube, but
it works with /var/lib/roundcube

Note that I update the open_basedir each time, and absolutely no message show in
the logs concerning fails to write in /var/tmp or /tmp (only when I forget to
change the open_basedir value for php). Any idea where it can come from? Did I
miss something in apache (or php?) configuration?

Thanks in advance!
-- 
Ismael


signature.asc
Description: Digital signature

Re: [arch-general] Apache (Roundcube) and /tmp

[Ismael Bouya]

(Sun, Jun 15, 2014 at 12:29:11PM -0500) Doug Newgard :
 On 2014-06-15 12:10, Ismael Bouya wrote:
 Hi,
 I tried to install roundcube (in community/), but it fails when it tries
 to
 check if he can write in his temp dir, which is a symlink that points to
 /tmp/roundcube and is rwx for http (and group http too).
 
 I have the same problem if I try to put the symlink to /var/tmp/roundcube,
 but
 it works with /var/lib/roundcube
 
 Note that I update the open_basedir each time, and absolutely no message
 show in
 the logs concerning fails to write in /var/tmp or /tmp (only when I forget
 to
 change the open_basedir value for php). Any idea where it can come from?
 Did I
 miss something in apache (or php?) configuration?
 
 Thanks in advance!
 
 Has also been reported on the bugtracker, but with no resolution.
 
 https://bugs.archlinux.org/task/40643

Oh I thought it was misconfiguration on my part.

It's strange that you get error messages about the open_basedir while I get
absolutely no information, no matter in which log file I look

-- 
Ismael


signature.asc
Description: Digital signature

Re: [arch-general] Starting gpg-agent from systemd?

[Ismael Bouya]

(Tue, Jun 10, 2014 at 03:06:12PM +0200) Bjørnar Hansen :
 On Sun, Jun 8, 2014 at 10:21 PM, Magnus Therning mag...@therning.org wrote:
  I did the following
 
  - start the systemd service envoy@ssh-agent.socket
  - add pam_envoy.so to /etc/pam.d/system-login
 
  That got it working for ssh, but not for gpg.  Is there something else
  I should do to also get gpg-agent support?
 
 Did you also start the systemd service envoy@gpg-agent.socket?

No, you cannot start both.  
However, if you start the gpg-agent version then you automatically have the
ssh-agent with it. It's more or less the same as the legacy gpg-agent. As
far as I am concerned I don't like that and prefer to separate ssh agent
from gpg agent (KISS, bla bla), so to answer to the OP more precisely and
without using envoy:

For gpg-agent, you can add something like that in your
$HOME/.config/systemd/user/gpg-agent.service
---
[Unit]
Description=gpg-agent
ConditionFileIsExecutable=/usr/bin/gpg-agent

[Service]
ExecStart=/usr/bin/gpg-agent --daemon --write-env-file %h/.gpg-agent-info
Type=forking
Restart=always
--
and make sure that it is started by your systemd session. For that refer to
the archlinux wiki: https://wiki.archlinux.org/index.php/Systemd/User

Then, any application that needs it should simply source the file
source $HOME/.gpg-agent-info
(for instance in your bashrc)

This is not a good solution for two reasons:
- You can have race condition between the gpg-agent start and the bash
  start, which will then source a wrong file. You have no way to prevent
  that as your session starts in parallel with the user-services
- Same problem if by chance the gpg agent fails and restart, putting his
  socket somewhere else (which it will).

There has been a ticket about that in the gpg mailing-list, which they
chose not to address
http://lists.gnupg.org/pipermail/gnupg-devel/2012-October/026983.html
So there is not really a solution so far.

For ssh-agent it's a bit simpler:
$HOME/.config/systemd/user/ssh-agent.service

[Unit]
Description=ssh-agent
ConditionFileIsExecutable=/usr/bin/ssh-agent

[Service]
ExecStart=/usr/bin/ssh-agent -d -a %t/ssh_auth_sock
Restart=always

And in your .bashrc/.xsession you simply need to add a 
export SSH_AUTH_SOCK=/var/run/user/1000/ssh_auth_sock

The above problem won't show up as we can force the agent to put it's
socket in a predictable place.

Cheers,
-- 
Ismael


signature.asc
Description: Digital signature

Re: [arch-general] Starting gpg-agent from systemd?

[Ismael Bouya]

(Fri, Jun 06, 2014 at 07:14:45PM +0200) Magnus Therning :
 The instructions at [^1] are for the shell and for using ~/.xinitrc to
 start X.  So neither is very well suited for me as I'm letting GDM log
 me in to Gnome without use of ~/.xinitrc and the agent has to be
 available also to apps started via Gnome Shell.

I forgot about this part.
Without using xinitrc, GDM sources some file. I don't remember if it is
your $HOME/.xsessionrc or $HOME/.profile (or both), but you should have a
look into gdm files (pacman -Ql ...) for a file called Xsession, and
there he will tell you which files are sourced before actually running
your session. You can then add any command you like.

-- 
Ismael


signature.asc
Description: Digital signature

Re: [arch-general] systemd-run --user does not work

[Ismael Bouya]

(Wed, May 14, 2014 at 09:45:40AM +0200) Yamakaky :
 Now I understand why sometimes I have two dbus daemons, thanks ! It's because 
 I
 manage tmux with systemd --user, and $DBUS is set by my xorg session not 
 managed
 by systemd.

Watch out about that. It's tempting to have your tmux managed by systemd
services (did you enable lingering to be sure that it doesn't get
killed when you exit your sessions?). And I do too.

However, to make it simple, a shell part of a service is not equivalent
to a shell in the session scope of the user, so you should expect
problems with that (if you ever get lost, the command systemd-cgls is a
good way to find out in which kind of scope your processes are).

In particular, a service is never considered active by systemd, and
this can create problems when in interaction with polkit (for instance),
where the same command (shutdown is the best known example) will be
accepted without needing sudo in a regular shell while it will be refused
in a shell part of a service.

I don't say of course that you shouldn't do it, just keep in mind that
it's not equivalent :p

 
 In fact, why isn't there a user unit for dbus by default ?

That's a good question!
-- 
Ismael


signature.asc
Description: Digital signature

Re: [arch-general] systemd-run --user does not work

[Ismael Bouya]

Hi,

I don't know if it's necessary to send the request upstream for the moment:
They are busy moving things to kdbus (which is the kernel implementation of
dbus, and not KDE-dbus as I thought initially).

Things are actually slightly messed up currently (that's my opinion, when I
spent time reading the systemd code to write my tutorial). The best thing
to be sure that everything works is to make sure that all of your processes
have the information about DBUS_SESSION_BUS_ADDRESS, and the same
information (and that dbus --session is started also, of course). Some
processes spawn a dbus when they cannot find one, which makes things harder
to debug (because they won't complain but it won't work as expected as they
will have their own bus and noone can talk to them. And you end with two
dbus processes just for you)

About the difference between systemd-run and systemctl: I didn't have a
close look at the systemd-run code, but they seem to have a different way
of implementing dbus connections (which might come from the comment above,
or simply legacy code). And I also ran into trouble with systemctl when I
didn't have the DBUS part (I cannot remember which kind of problems, but
that's where I started to dive into details of systemd implementation)


So to sum up: if you have it everywhere it works; so why not put it and
forget about it (it's not so hard to ensure actually).


-- 
Ismael


signature.asc
Description: Digital signature

Re: [arch-general] systemd-run --user does not work

[Ismael Bouya]

(Mon, May 12, 2014 at 11:23:33PM +0900) Savyasachee Jha :
 Well, I just tried this out on my laptop, and it gives two different error
 messages.
 
 $ sysytemd-run --user /usr/bin/ls
 Failed to create message: Input/output error
 
 $ sudo systemd-run --user /usr/bin/ls
 Failed to create bus connection: Connection refused
 
 And yes, running it with --system works perfectly well. It is very odd.

(This answer is a summary of a tutorial that I wrote some days ago and you
can find the french version here:
http://immae.eu/blog/2014/05/10/gerer-sa-session-avec-systemd/
If you don't speak french, be patient, I'm working on its translation)



For me it works both with user and system.

It works for system:
That's normal, because systemd makes use of dbus, and the system bus is
always there, and he knows where to contact it.

However, systemd-run --user tries to contact the user dbus (AKA session
dbus), via your systemd --user (You can see it with pstree -aUp login
if it is started. If it is not, then probably you should enable the correct
module via pam). Does this process know your dbus session? If you didn't do
anything regarding that, then certainly not.

You can be sure by checking its environment which should contain something
like that:
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus

Let's say you don't have it in systemd --user. Simply add something like
that in /etc/systemd/system/user@.service.d/dbus_env.conf

[Unit]
Wants=dbus.service

[Service]
Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/%I/bus
-
and follow the DBUS section there:
https://wiki.archlinux.org/index.php/Systemd/User#D-Bus

This will ensure that you have a dbus session and that all the services
(including systemd --user) know how to have access to it.

Then you can run your systemd-run --user. You have to restart *all* your
sessions before that of course (I.e. you muss not have any remaining
session at your name, otherwise the process won't end. Check that with
systemd-cgls or so. If you enabled lingering sessions then you probably
don't have this problem, otherwise make sure everything is killed)


(Note that your shell doesn't have to know the DBUS_SESSION_BUS_ADDRESS
variable)
-- 
Ismael


signature.asc
Description: Digital signature

Re: [arch-general] Comment on: Use systemd timers instead of /etc/cron.{hourly, daily, weekly, monthly}?

[Ismael Bouya]

(Tue, May 06, 2014 at 04:28:48PM -0400) Daniel Micay :
 On 06/05/14 04:13 PM, Leonid Isaev wrote:
 
  After re-reading the documentation I have to take this back, systemd timers
  seem to implement all features provided by cronie.
 
 AFAIK, the only notable missing feature is the ability for non-root
 users to run jobs when they're not logged in. This is intentionally left
 out, and it's not hard for an administrator to replicate the feature
 with a timer unit for a specific user allowed to run jobs.

Note that
loginctl enable-linger user
launches the systemd of user even when he is not there
-- 
Ismael


signature.asc
Description: Digital signature

[arch-general] Automatic upgrade

[Ismael Bouya]

Hi,
I know it is highly discouraged and that it can break the machine, but I
have a good reason to do it anyway:
It's highly unpractical to me to access the machine from where I am --
even remotely: I need someone to manually open a tunnel each time I want
to access the machine --, and the other person who has root access to the
machine doesn't think of doing the upgrade regularly: Last upgrade was 2
months ago, despite regular reminders.

However I want to do it the best way:
- Check that the Arch news didn't change
- ssh is run as a service and not a socket (it's a headless machine)
- Ignore ssh, linux, grub upgrades
- Transmit the log by email (I *will* read it)
- Send by email the list that will be upgraded before doing the upgrade

Anything else I should check before running an automatic upgrade? Any
other advice?

Thanks in advance for any advice!

Best regards,
-- 
Ismaël


signature.asc
Description: Digital signature

Re: [arch-general] Automatic upgrade

[Ismael Bouya]

(Tue, Feb 11, 2014 at 12:56:39PM +0100) Florian Pritz :
 On 11.02.2014 11:42, Ismael Bouya wrote:
  It's highly unpractical to me to access the machine from where I am --
  even remotely: I need someone to manually open a tunnel each time I want
  to access the machine --
 
 Set up an automatic tunnel (simple service that just runs autossh or
 similar) or use a VPN (openvpn, tinc) and do the upgrade yourself.

That's not an option. The network on which the machine is is willingly
inaccessible from outside: The sysadmin there has the principle that a
machine that works shouldn't be upgraded, because then it can
break... (The machine which has Archlinux is an exception and he's not
aware of its existence) It's one thing to ask someone to manually create a
tunnel so that I can access the machine once in a while. It's another one
to bypass the sysadmin politics and risk problems if anything happens.

 Automatic upgrades won't work if there are conflicts which sadly happens
 quite a few times every year.

Sure, but I can do it manually then... 
-- 
Ismael


signature.asc
Description: Digital signature

Re: [arch-general] Automatic upgrade

[Ismael Bouya]

(Tue, Feb 11, 2014 at 01:20:12PM +0100) pala...@jstation.cz :
 That's not an option. The network on which the machine is is willingly
 inaccessible from outside: The sysadmin there has the principle that a
 machine that works shouldn't be upgraded, because then it can
 break...
 
 That's pretty idiotic attitude. Even working machine needs security
 patches etc.

I do agree with you on that point, and on many others which you cannot
imagine before you face it, but that's not something I can change. (Just
in case it wasn't clear: I'm obviously not that person) 

-- 
Ismael


signature.asc
Description: Digital signature

Re: [arch-general] Automatic upgrade

[Ismael Bouya]

(Tue, Feb 11, 2014 at 01:29:30PM +0100) Constantin :
 You could establish a VPN/tunnel originating from the server you want to
 update. That way, from the machine's view, it is an outgoing connection
 and might not be restricted by the firewall. You can then use the
 existing tunnel to ssh back to the machine.
 Of course this would require an accessible server somewhere outside.

Sure, that's what I understood in the former message, and already thought
of doing it. The problem that I have (maybe it wasn't clear in my message)
is that then I give an obvious *permanent* entry point to a network that
is willingly closed. If anything happens (even if I'm quite confident with
the security of the machine, we never know), it's my responsibility, and I
don't want that.

-- 
Ismael


signature.asc
Description: Digital signature

Re: [arch-general] Automatic upgrade

[Ismael Bouya]

 How about establishing regular maintenance intervals?
 
 This way, the VPN could be active on these times for you to use and be
 disabled the rest of the time. Depending on the setup, this could be easily
 automated. If i understand the admin correctly, he'll be happy with the
 fixed timing (easier to plan for).

Yes, that's more or less what I was starting to think of after Al O'Nerd
suggestion (which was better than what I thought of so far but still had
the problem of a potential undesired access while I'm not there), but you
put it in words better than me.

Thanks all for your help!
-- 
Ismael


signature.asc
Description: Digital signature

Re: [arch-general] Automatic upgrade

[Ismael Bouya]

(Tue, Feb 11, 2014 at 07:00:41PM +0100) Rodrigo Rivas :
 My guess here is that this secure network is full of non-upgraded
 (Windows?) machines, and security is attained exclusively by network
 isolation.

No they are all on linux. The problem here is that it creates a lot of
problem for work: outdated browser (some websites unaccessible), outdated
bash and programs (Hard to believe, but they have evolved a lot!!). We must
do everything by ourselves, hence the hidden machine: to handle backup of
our datas since he doesn't do it properly (last year his backup/nfs server
failed and we stayed a few months with an inconsistently rebuilt home, and
the emergency solution went to break also afterwards and...)

 So my advice to the OP is to play safe and not to program any kind of
 inbound tunnel. That could end in disaster and you would be responsible!
 Just limit the access to your mole's handmade tunned, or play by the rules
 and not upgrade (ug!).

Hum hum... I'm still hesitating on what exactly I will do, but it won't
stay like that...

Anyway, thanks all for all the advices!
-- 
Ismael


signature.asc
Description: Digital signature

Re: [arch-general] Automatic upgrade

[Ismael Bouya]

(Tue, Feb 11, 2014 at 09:51:10PM -0300) Hugo Osvaldo Barrera :
 Can the machine download emails from a remote server?
 You could set something up that downloads emails from a certain mailbox,
 validates they're PGP signature, and runs the body as a shell script.
 Tedious, but it works.

Yes (I didn't test it actually but I think I can have it), but it's
always the same problem: I have to trust something (a GPG key, an SSH
key, a VPN, a machine, whatever...) outside of the closed network.


The advantage of what I was trying to do in the first place (automatic
upgrades) is that I don't need to open a hole to access the machine as
long as there is no problem.

-- 
Ismael


signature.asc
Description: Digital signature

Re: [arch-general] Initramfs fallback render

[Ismael Bouya]

Hum I started to write answers to different emails, but it looks like I
messed things between an actual problem (A non-critical hard disk that
crashed with no nofail option in the fstab) and my tries afterwards to
boot in rescue/emergency mode.

To answer to Gaëtan, the message that I saw was exactly the one in
/usr/lib/systemd/system/{rescue,emergency}.service 
I know the difference is important but I cannot remember which one it was
(most probably it's the one corresponding to what happens when things go
bad)

Mainly, I made a confusion with what is usual in Ubuntu in the grub, that
is to have a line for normal booting, and one line for emergency, that
tries as hard as possible to reach a (root) shell even when things go
badly.

Now I know that I'll have to configure this behavior somehow manually (?)

Thanks all for your help!

Best regards,
-- 
Ismael


signature.asc
Description: Digital signature

Re: [arch-general] Initramfs fallback render

[Ismael Bouya]

(Fri, Nov 15, 2013 at 09:45:15AM +0100) Rodrigo Rivas :
 On Fri, Nov 15, 2013 at 1:55 AM, Ismael Bouya
 ismael.bo...@normalesup.orgwrote:
  However when we need to boot into fallback mode, initramfs asks for root
  password! Is there a standard/automated way to ask/permit another user via
  initramfs in Archlinux?
 
 
 ...because you should only do that when your boot console is secure. The
 argument is that if anyone has physical access to your computer, they can
 boot from a LiveCD or USB anyway...


Well, that's how I dealt with my problem, I was lucky that I had one, but...


 
  If not, how do you deal with that usually?
 
 
 Let's go to the point! The pasword is asked by the systemd services
 emergency.service or rescue.service, that run /sbin/sulogin.
 
 So your easiest solution is to modify these services to use the argument
 --force, that according to man sulogin will do what you want:
 
 For that create the directory /etc/systemd/system/emergency.service.d and
 in it the file 10-nopasswd.conf with this content:
 
 [Service]
 ExecStart=-/sbin/sulogin --force
 
 And the same repacing rescue for emergency.

Hum that will accept passwordless login wont it? I was telling of accepting
a specific (trusted) user's password instead of root's

But at least I know now which direction to look at, I'll test it next time
I have physical access to my computer, and report..

Thanks!

-- 
Ismael


signature.asc
Description: Digital signature

Re: [arch-general] Initramfs fallback render

[Ismael Bouya]

(Fri, Nov 15, 2013 at 02:52:33PM +0100) Rodrigo Rivas :
 Yes, I thought that was the point. But you want to use the user password...
 the same as with sudo, makes sense.
 You could using login instead of sulogin. Or if you feel brave enough
 you could even add a link to getty@tty2.service or getty@tty1.service
 into /etc/systemd/system/{rescue,emergency}.target.wants and see what
 happens (you may have to manually switch to VT2, though).

Yes, that's what more or less what I thought about and just did, if I break
something up to a point that even this solution doesn't work then maybe I
reached a point where it might be a good idea to boot from a key :)

Thanks a lot!

Mvh,
-- 
Ismael


signature.asc
Description: Digital signature

Re: [arch-general] Initramfs fallback render

[Ismael Bouya]

(Fri, Nov 15, 2013 at 06:00:58PM +0100) Ismael Bouya :
 (Fri, Nov 15, 2013 at 02:52:33PM +0100) Rodrigo Rivas :
  Yes, I thought that was the point. But you want to use the user password...
  the same as with sudo, makes sense.
  You could using login instead of sulogin. Or if you feel brave enough
  you could even add a link to getty@tty2.service or getty@tty1.service
  into /etc/systemd/system/{rescue,emergency}.target.wants and see what
  happens (you may have to manually switch to VT2, though).
 
 Yes, that's what more or less what I thought about and just did, if I break
 something up to a point that even this solution doesn't work then maybe I
 reached a point where it might be a good idea to boot from a key :)

By the way I came to a dark point : how does systemd knows that he is
started in fallbackmode ?

I see no difference in the grub.cfg in the kernel options, and no
relevant differences in the initramfs (more modules available and a few
lines in .../modules.devname)

Did I miss something or is he doing magic with the name of the initrd
file?

I found no information of how systemd does that (for the rescue there is
a kernel option in the man file, but for the emergency there is nothing)
-- 
Ismael


signature.asc
Description: Digital signature

[arch-general] Initramfs fallback render

[Ismael Bouya]

Hi all,

I have always learnt that it was good practice (to use sudo instead of root
su and), when we use sudo, to completely disable root login (by disabling
his password).

However when we need to boot into fallback mode, initramfs asks for root
password! Is there a standard/automated way to ask/permit another user via
initramfs in Archlinux?

If not, how do you deal with that usually?


Thanks in advance for your response!

Regards,
-- 
Ismael


signature.asc
Description: Digital signature

Re: [arch-general] systemd --test

[Ismael Bouya]

(Mon, Nov 04, 2013 at 07:57:04AM -0800) John Davis :
 Hello Folks,
 
 I believe you want to run systemctl instead of systemd.  The archwiki entry
 on systemd is very well written.  The parameters to systemctl are given
 with examples.

No,
it is a systemd command and not a systemctl command (As seen in man
systemd and not in systemctl). However the behavior seen by the first
poster (And that I can reproduce) suggests that maybe --test is ignored
(I also tried to run it and got the same thing with --test as without)
-- 
Ismael


signature.asc
Description: Digital signature