Re: Filter logcheck reboot messages?

[Richard Hector]

On 10/12/17 04:01, Ulf Volmer wrote:
> On 09.12.2017 15:37, Sven Hartge wrote:
>> Richard Hector  wrote:
>>
>>> Nobody else uses logcheck? Everyone is fine with how it works?
>>
>> I use logcheck on all systems and I see no need to change it. In fact, I
>> *want* the reboot messages and filtering them out would be a regression
>> for me.
> 
> Agree. i'm using logcheck to give me information about unexpected
> behavior and i count a reboot as unexpected behavior.

I would be happy to be notified of a reboot, even when it is expected.

But I don't need screeds of kernel messages, which given that a reboot
happened, are normal - except that I don't know which ones are normal
and which might not be.

Also, I don't expect everyone else's requirements to be the same as mine
- but filtering out the noise from reboot messages would be useful to me.

Richard




signature.asc
Description: OpenPGP digital signature

Re: Embarrassing security bug in systemd

[The Wanderer]

On 2017-12-09 at 09:10, Brian wrote:

> The Terms and Conditions of installing a Debian package include (as 
> I'm sure you are aware) accepting the Depends: and Recomends: lines. 
> What is in these lines can be accepted or rejected and, in the case 
> of Recommends:, adjusted to suit your needs. Installing the package 
> necessarily involves making an explicit request for other packages.

No, it doesn't. That's the exact distinction between "explicit" and
"implicit".

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Embarrassing security bug in systemd

[Dejan Jocic]

On 09-12-17, Brian wrote:
> On Sat 09 Dec 2017 at 20:07:17 +0100, Dejan Jocic wrote:
> 
> > On 09-12-17, Jonathan Dowland wrote:
> > > On Sat, 2017-12-09 at 10:00 +, Brian wrote:
> > > > Consistencey can be achieved by not installing policykit. The OP
> > > > appears to have chosen the wrong target.Consistencey can be achieved > 
> > > > by not installing policykit.
> > > 
> > > As Michael pointed out in [1], that's not the case; prior to polkit,
> > > there was no consistency.
> > > 
> > > 
> > > [1]  <8430b277-3757-8261-0e1e-23e274a0b...@debian.org>
> > > 
> > 
> > Is it anywhere in Debian documentation described how to achieve
> > consistency in a way different than current defaults? Or, even better,
> > is there way that we could get some kind of configuration option to
> > achieve it? Polkit does not really have user friendly configuration and
> > is not really something that system administrators configure on a
> > everyday bases. At least not in my experience. Only thing that I did
> > find about configuring polkit was from some other distros. Debian wiki
> > page about PolicyKit is not really helpful.
> 
> Apart from not installing policykit, setting allow_active to "no" in
> /usr/share/polkit-1/actions/org.freedesktop.login1.policy would do it.
> 
> Much better is to use /etc/polkit-1/localauthority. See the manual for
> pklocalauthority.
> 
> -- 
> Brian.
> 

Man page for pklocalauthority is bit more helpful, but far from self
explanatory. In its examples section, it provides some insight about
writing .pkla files, but it does not show all possible options, or at
least I can't be sure that it does. For example:

[Exclude Some Problematic Users]
   Identity=unix-user:homer;unix-user:grimes
   Action=com.example.awesomeproduct.*
   ResultAny=no
   ResultInactive=no
   ResultActive=auth_admin

According to that, and after reading man page for polkit, I can only
deduct that .pkla file will for that example in that
com.example.awesomeproduct.* files reads lines under defaults and
"answer" on allow_any and allow_inactive with no value and on
allow_active with auth_admin value. Fine, that can work. Guess that you
can use wildecards for all users, like unix-user:*, but that is only
guess, cause I can't see it documented anywhere ( might have missed it).
What I also do not see anywhere is if those are the only options
available? Or there is some man page, or additional documentation in
Debian that can explain that?

Thank you for your time,
Dejan

Re: Embarrassing security bug in systemd

[Ben Caradoc-Davies]

On 10/12/17 04:45, Tom Furie wrote:

On Sat, Dec 09, 2017 at 10:17:45AM -0500, Ric Moore wrote:

On 12/08/2017 05:12 PM, Cindy-Sue Causey wrote:

Something I did *not* understand when I saw it in operation was why
a password was needed at the terminal but not from within the GUI's
"Applications > Log Out" menu path.

Thank you Cindy, now I don't have to point out the obvious! :) Ric

Apart from the minor detail where in a properly network transparent
environment X sessions do not always occur at the console.


Polkit can tell the difference:

- Local XFCE shutdown (debian/sid, systemd): no prompt

- Remote XFCE shutdown via VNC tunnelled through SSH (Ubuntu 16.04 LTS, 
systemd): password prompt


I think these are sensible defaults.

Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Re: Embarrassing security bug in systemd

[Brian]

On Sat 09 Dec 2017 at 20:07:17 +0100, Dejan Jocic wrote:

> On 09-12-17, Jonathan Dowland wrote:
> > On Sat, 2017-12-09 at 10:00 +, Brian wrote:
> > > Consistencey can be achieved by not installing policykit. The OP
> > > appears to have chosen the wrong target.Consistencey can be achieved > by 
> > > not installing policykit.
> > 
> > As Michael pointed out in [1], that's not the case; prior to polkit,
> > there was no consistency.
> > 
> > 
> > [1]  <8430b277-3757-8261-0e1e-23e274a0b...@debian.org>
> > 
> 
> Is it anywhere in Debian documentation described how to achieve
> consistency in a way different than current defaults? Or, even better,
> is there way that we could get some kind of configuration option to
> achieve it? Polkit does not really have user friendly configuration and
> is not really something that system administrators configure on a
> everyday bases. At least not in my experience. Only thing that I did
> find about configuring polkit was from some other distros. Debian wiki
> page about PolicyKit is not really helpful.

Apart from not installing policykit, setting allow_active to "no" in
/usr/share/polkit-1/actions/org.freedesktop.login1.policy would do it.

Much better is to use /etc/polkit-1/localauthority. See the manual for
pklocalauthority.

-- 
Brian.

Re: Embarrassing security bug in systemd

[Gene Heskett]

On Saturday 09 December 2017 12:01:59 David Wright wrote:

> On Sat 09 Dec 2017 at 11:29:58 (-0500), Gene Heskett wrote:
> > On Saturday 09 December 2017 05:12:16 Joe wrote:
> > > On Fri, 8 Dec 2017 23:56:44 +
> > >
> > > Brian  wrote:
> > > > On Fri 08 Dec 2017 at 23:06:00 +, Joe wrote:
> > > > > On Fri, 8 Dec 2017 17:12:18 -0500
> > > > >
> > > > > Cindy-Sue Causey  wrote:
> > > > > > I do remember having to give a password, but I don't
> > > > > > remember how long ago now. And I have too much open right
> > > > > > now to test drive whether mine does it or not these days..
> > > > > > :)
> > > > >
> > > > > As I did the other day. I've tried it now (up-to-date
> > > > > unstable) and it works for a non-root user.
> > > >
> > > > Without policykit-1 installed it doesn't; no rebooting or
> > > > powering off with /sbin/reboot or /sbin/poweroff for a user.
> > > > CTRL+ALT+DEL from a terminal reboots. That's the same behaviour
> > > > as sysvinit.
> > >
> > > Yes, I understand that, the point is that the first installation
> > > of policykit-1, which I did not explicitly request, did not ask me
> > > if I wanted non-root users to be able to reboot, or indeed about
> > > anything else it might control. Not that it matters on any of my
> > > machines, I'd just like to have been told that it was changing,
> > > and given the option to keep it as it was had I needed to.
> >
> > Thats another very sore point. Where are the man pages? Its
> > installed on 6, maybe 7 machines here, with zero docs. What the
> > hell? If debian or any other distro decides to shove this crap down
> > our throats, at least have the courtesy of making the docs
> > available. I just searched thru the repo's with synaptic and came up
> > null and empty on polkit-1.
> >
> > So where are the docs?
>
> $ dpkg -L policykit-1 | less
> will reveal what came with the package, and you'll find the
> manpages listed there, about 7 of them.
>
> Cheers,
> David.

I see that David, but when the name is not consistent, it comes across as 
yet another attempt to keep it all a secret from those not in the know, 
but are just harassed to tears by the effects of this stuff.

In case you hadn't noticed, polkit-1 /= policykit-1 when doing a search. 
So lets at least have a consistent name, and a lot of the fire and name 
calling will go away simply because we CAN find the docs. And if the 
deocs are complete enough, maybe even fix our bitches.

As it exists now, the miss-matched names are seen as nothing but 
obfuscation, purposely designed to prevent the users from over-riding 
its ill-formed (to us who have been running an all linux house for the 
last 19 years, and used Amiga's for a decade before that) rules choices. 
Linux is supposedly all about freedom of choice, so give it back to us 
instead of having to constantly feed the flame war just to get the info 
we need, which is as you are well aware, difficult to do without making 
some enemies.

Thank you David, for emitting that bit of information and helping the 
rest of us. 

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: Embarrassing security bug in systemd

[Roberto C . Sánchez]

On Sat, Dec 09, 2017 at 06:20:01PM +, Jonathan Dowland wrote:
> On Sat, 2017-12-09 at 10:00 +, Brian wrote:
> > Consistencey can be achieved by not installing policykit. The OP
> > appears to have chosen the wrong target.Consistencey can be achieved > by 
> > not installing policykit.
> 
> As Michael pointed out in [1], that's not the case; prior to polkit,
> there was no consistency.
> 
There are multiple dimensions of consistency.  PolicyKit may provide may
provide consistency in terms of centralizing configuration so that
various disparate components behave in some predictable fashion across
those components.  Without installing PolicyKit is the various
components behave in their historically independent ways.  That in
itself is just a different form of consistency.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: Embarrassing security bug in systemd

[Brian]

On Sat 09 Dec 2017 at 18:20:01 +, Jonathan Dowland wrote:

> On Sat, 2017-12-09 at 10:00 +, Brian wrote:
> > Consistencey can be achieved by not installing policykit. The OP
> > appears to have chosen the wrong target.Consistencey can be achieved > by 
> > not installing policykit.
> 
> As Michael pointed out in [1], that's not the case; prior to polkit,
> there was no consistency.

We are at cross-purposes. Don't install policykit and a pre-systemd and
a systemd system behave in the same way wrt /sbin/reboot. Is this the
sort of advice people think should have been in the Release Notes?

-- 
Brian.

Public folder in plasma?

[Hans]

Dear list,

maybe someone might remember, that in kde2 (or kde3?) was an option 
implemented, that one could add a public folder, to let people get access to 
it. This was a nifty little application, which was running in the taskbar.

In this folder you could put any files, you want to share with the public.

That folder could be reached via an URL, like http://something/foldername.

I know, in plasma, folders can be made public with samba, but I do not want to 
install samba on my netbook. 

This folder in kde2 (or 3?) was made for me moment and it got its own http-
demon.

Does anyone remember this thing and can tell me, if such a thing is available 
on plasma, too. Maybe with an external widget or app? I saw "kepas", but I 
forgot about the name of the plugin.

Hope, there is a modern plugin, which can do the same as the one in kde2 (or 
kde3?) 

Any hints are welcome!

Thank you very much and have a nice weekend

Hans 

Re: Embarrassing security bug in systemd

[Dejan Jocic]

On 09-12-17, Jonathan Dowland wrote:
> On Sat, 2017-12-09 at 10:00 +, Brian wrote:
> > Consistencey can be achieved by not installing policykit. The OP
> > appears to have chosen the wrong target.Consistencey can be achieved > by 
> > not installing policykit.
> 
> As Michael pointed out in [1], that's not the case; prior to polkit,
> there was no consistency.
> 
> 
> [1]  <8430b277-3757-8261-0e1e-23e274a0b...@debian.org>
> 

Is it anywhere in Debian documentation described how to achieve
consistency in a way different than current defaults? Or, even better,
is there way that we could get some kind of configuration option to
achieve it? Polkit does not really have user friendly configuration and
is not really something that system administrators configure on a
everyday bases. At least not in my experience. Only thing that I did
find about configuring polkit was from some other distros. Debian wiki
page about PolicyKit is not really helpful.

Thank you for your time,
Dejan

Re: Embarrassing security bug in systemd

[Jonathan Dowland]

On Sat, 2017-12-09 at 10:00 +, Brian wrote:
> Consistencey can be achieved by not installing policykit. The OP
> appears to have chosen the wrong target.Consistencey can be achieved > by not 
> installing policykit.

As Michael pointed out in [1], that's not the case; prior to polkit,
there was no consistency.


[1]  <8430b277-3757-8261-0e1e-23e274a0b...@debian.org>

Re: connexion ssh semi-automatique

[Eric Degenetais]

En fait, ça dépend du niveau de sécurité souhaité : il peut être nécessaire
de protéger la clef privée côté client par un mot de passe pour éviter
qu'elle soit volée. Dans ce cas, l'utilisateur doit entrer un mot de passe,
avec les avantages suivants sur un mot de passe classique :
1-le mot de passe ne circule pas sur le réseau
2-s'il est volé pour une raison ou une autre, le mot de passe ne suffit pas
à entrer sur la machine distante

Cordialement

Éric Dégenètais

Le 9 déc. 2017 6:19 PM,  a écrit :

> > > Le 9 déc. 2017 à 09:29, amandine SZCZYGIEL Z.elec wrote :
> > > Le plus simple est de ne pas mettre de mot de passe et
> > > d'utiliser une passkey avec un utilisateur crée spécifiquement
> > > sur ta machine.
>
> Avec une paire de clés publique et privée,
> pas besoin de taper un mot de passe.
>
> André
>
>

Re: connexion ssh semi-automatique

[andre_debian]

> > Le 9 déc. 2017 à 09:29, amandine SZCZYGIEL Z.elec wrote :
> > Le plus simple est de ne pas mettre de mot de passe et 
> > d'utiliser une passkey avec un utilisateur crée spécifiquement 
> > sur ta machine.  

Avec une paire de clés publique et privée,
pas besoin de taper un mot de passe.

André

Re: Embarrassing security bug in systemd

[David Wright]

On Sat 09 Dec 2017 at 11:29:58 (-0500), Gene Heskett wrote:
> On Saturday 09 December 2017 05:12:16 Joe wrote:
> 
> > On Fri, 8 Dec 2017 23:56:44 +
> >
> > Brian  wrote:
> > > On Fri 08 Dec 2017 at 23:06:00 +, Joe wrote:
> > > > On Fri, 8 Dec 2017 17:12:18 -0500
> > > >
> > > > Cindy-Sue Causey  wrote:
> > > > > I do remember having to give a password, but I don't remember
> > > > > how long ago now. And I have too much open right now to test
> > > > > drive whether mine does it or not these days.. :)
> > > >
> > > > As I did the other day. I've tried it now (up-to-date unstable)
> > > > and it works for a non-root user.
> > >
> > > Without policykit-1 installed it doesn't; no rebooting or powering
> > > off with /sbin/reboot or /sbin/poweroff for a user. CTRL+ALT+DEL
> > > from a terminal reboots. That's the same behaviour as sysvinit.
> >
> > Yes, I understand that, the point is that the first installation of
> > policykit-1, which I did not explicitly request, did not ask me if I
> > wanted non-root users to be able to reboot, or indeed about anything
> > else it might control. Not that it matters on any of my machines, I'd
> > just like to have been told that it was changing, and given the option
> > to keep it as it was had I needed to.
> 
> Thats another very sore point. Where are the man pages? Its installed on 
> 6, maybe 7 machines here, with zero docs. What the hell? If debian or 
> any other distro decides to shove this crap down our throats, at least 
> have the courtesy of making the docs available. I just searched thru the 
> repo's with synaptic and came up null and empty on polkit-1.
> 
> So where are the docs?

$ dpkg -L policykit-1 | less
will reveal what came with the package, and you'll find the
manpages listed there, about 7 of them.

Cheers,
David.

Re: Embarrassing security bug in systemd

[David Wright]

On Sat 09 Dec 2017 at 10:17:45 (-0500), Ric Moore wrote:
> On 12/08/2017 05:12 PM, Cindy-Sue Causey wrote:
>  Something I did *not* understand when I saw it in
> >operation was why a password was needed at the terminal but not from
> >within the GUI's "Applications > Log Out" menu path.
> 
> Thank you Cindy, now I don't have to point out the obvious! :) Ric

I don't know what's obvious. I also don't know what is meant
in the above by "terminal". Is it a linux VC (pre-X/DE),
a VC summoned from X, a POX (plain old xterm) or some DE-moderated
terminal that I've never used? It would also be nice to know
what the command was that was typed. (I'm also assuming that
systemd was likely installed, and we're talking stretch.)

Sorry about all the alsos, but there are a lot of variables at
play here.

Cheers,
David.

Re: Embarrassing security bug in systemd

[Gene Heskett]

On Saturday 09 December 2017 05:12:16 Joe wrote:

> On Fri, 8 Dec 2017 23:56:44 +
>
> Brian  wrote:
> > On Fri 08 Dec 2017 at 23:06:00 +, Joe wrote:
> > > On Fri, 8 Dec 2017 17:12:18 -0500
> > >
> > > Cindy-Sue Causey  wrote:
> > > > I do remember having to give a password, but I don't remember
> > > > how long ago now. And I have too much open right now to test
> > > > drive whether mine does it or not these days.. :)
> > >
> > > As I did the other day. I've tried it now (up-to-date unstable)
> > > and it works for a non-root user.
> >
> > Without policykit-1 installed it doesn't; no rebooting or powering
> > off with /sbin/reboot or /sbin/poweroff for a user. CTRL+ALT+DEL
> > from a terminal reboots. That's the same behaviour as sysvinit.
>
> Yes, I understand that, the point is that the first installation of
> policykit-1, which I did not explicitly request, did not ask me if I
> wanted non-root users to be able to reboot, or indeed about anything
> else it might control. Not that it matters on any of my machines, I'd
> just like to have been told that it was changing, and given the option
> to keep it as it was had I needed to.

Thats another very sore point. Where are the man pages? Its installed on 
6, maybe 7 machines here, with zero docs. What the hell? If debian or 
any other distro decides to shove this crap down our throats, at least 
have the courtesy of making the docs available. I just searched thru the 
repo's with synaptic and came up null and empty on polkit-1.

So where are the docs?

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: Embarrassing security bug in systemd

[David Wright]

On Fri 08 Dec 2017 at 18:30:08 (-0800), Jimmy Johnson wrote:
> On 12/07/2017 02:31 AM, Jonathan Dowland wrote:
> >On Thu, Dec 07, 2017 at 10:02:56AM +, Tixy wrote:
> >>I'm running Jessie (with systemd running but booting with sysvinit) and
> >>trying to execute halt/poweroff/reboot/shutdown from a terminal without
> >>root privileges gives an error saying I must be superuser. Which has
> >>always been my experience in 10 years of using Debian.
> >
> >Be careful to double check what you are testing: in your situation it's
> >not clear whether /sbin/reboot is a symlink to systemctl (part of
> >systemd, so I would expect this not to work if you were not running
> >systemd as the init system) or a separate binary.
> 
> 
> Jonathan, I started thinking about lost work where someone restarted
> the computer while I was away from it and thought what if you can
> lock-screen and lock access to console at the same time.  Is that
> something that could be done? Helpful?
> 
> I know someone can pull the cord or press the power button, I got past that.

I use vlock -a in a VC to lock all the consoles. I've been using
it for years so I hadn't noticed the -n switch that allows you to
run it in X (with switching to a VC first).

You can still ssh into, and scp to, the machine while it's locked.
AFAICT Debian's versions allow unlocking with the root password as
well as the user's, which is handy if you forget which username
you were logged in under when you vlock'd it.

https://lists.debian.org/debian-user/2017/11/msg00951.html

Cheers,
David.

Re: Embarrassing security bug in systemd

[Tom Furie]

On Sat, Dec 09, 2017 at 10:17:45AM -0500, Ric Moore wrote:
> On 12/08/2017 05:12 PM, Cindy-Sue Causey wrote:
> > Something I did *not* understand when I saw it in operation was why
> > a password was needed at the terminal but not from within the GUI's
> > "Applications > Log Out" menu path.
> 
> Thank you Cindy, now I don't have to point out the obvious! :) Ric

Apart from the minor detail where in a properly network transparent
environment X sessions do not always occur at the console.

Cheers,
Tom

-- 
A man may sometimes be forgiven the kiss to which he is not entitled,
but never the kiss he has not the initiative to claim.


signature.asc
Description: Digital signature

Re: on-screen artifacts (red pixels) at high resolution with Intel HD 630 (Kaby Lake)

[Benny Simonsen]

The image with errors looks as it was manipulated in a photoeditor, eg.
Gamma/levels curves ... Does the driver have some image adjustment enabled?

Re: Filter logcheck reboot messages?

[Sven Hartge]

Ulf Volmer  wrote:
> On 09.12.2017 15:37, Sven Hartge wrote:
>> Richard Hector  wrote:
 
>>> Nobody else uses logcheck? Everyone is fine with how it works?
>> 
>> I use logcheck on all systems and I see no need to change it. In
>> fact, I *want* the reboot messages and filtering them out would be a
>> regression for me.

> Agree. i'm using logcheck to give me information about unexpected
> behavior and i count a reboot as unexpected behavior.

This is also the reason why I prefer logcheck over logwatch. 

With logcheck you define "normal behavior" and it gets filtered out. The
rest is then per definition "abnormal behavior" and gets send via mail.

For logwatch on the other side you define the "abnormal behavior"
beforehand, which I find much more inconvenient and difficult, because I
mostly don't know if something is normal or not before I can see it.

S°

-- 
Sigmentation fault. Core dumped.

Re: Embarrassing security bug in systemd

[Ric Moore]

On 12/08/2017 05:12 PM, Cindy-Sue Causey wrote:
 Something I did *not* understand when I saw it in

operation was why a password was needed at the terminal but not from
within the GUI's "Applications > Log Out" menu path.


Thank you Cindy, now I don't have to point out the obvious! :) Ric


--
My father, Victor Moore (Vic) used to say:
"There are two Great Sins in the world...
..the Sin of Ignorance, and the Sin of Stupidity.
Only the former may be overcome." R.I.P. Dad.
http://linuxcounter.net/user/44256.html

Re: on-screen artifacts (red pixels) at high resolution with Intel HD 630 (Kaby Lake)

[David Wright]

On Sat 09 Dec 2017 at 15:35:18 (+0100), Alexandre Rossi wrote:
> > Screenshot [1] looks normal to me, but on screenphoto [2] I clearly see
> > red-ish stripes and pink spots in the middle.
> >
> > Now it looks like your LCD could be faulty not PC hardware\software. Can you
> > test it with another LCD monitor, or connect it to TV via HDMI cable if it's
> > possible?
> 
> The same TV and cable work fine at the same resolution with another PC
> and another laptop.
> The same TV, cable and same computer work fine if using Windows 10.
> 
> So the problem only happens with that PC _AND_ Linux/Xorg.

I'm no expert here, but I'd suspect the driver.

I'd also be looking systematically at gradations of known colours
(perhaps start with a colour wheel) to try and tie down where the
errors occur, and whether they're related to bit values, rollovers
(like 0FFF→1000), screen position, etc.

Cheers,
David.

Re: Filter logcheck reboot messages?

[Ulf Volmer]

On 09.12.2017 15:37, Sven Hartge wrote:
> Richard Hector  wrote:
> 
>> Nobody else uses logcheck? Everyone is fine with how it works?
> 
> I use logcheck on all systems and I see no need to change it. In fact, I
> *want* the reboot messages and filtering them out would be a regression
> for me.

Agree. i'm using logcheck to give me information about unexpected
behavior and i count a reboot as unexpected behavior.

best regards
Ulf

Re: connection ssh semi automatique

[daniel huhardeaux]

Le 09/12/2017 à 13:11, Pierre Malard a écrit :

Bonjour,

Avez vous regardé un outil comme « autossh » ? Cela fait exactement ce 
que vous suggérez et, avec un échange de clés, tout est transparent.


+1



Le 9 déc. 2017 à 09:29, amandine SZCZYGIEL Z.elec 
> a écrit :


Bonjour,
Le plus simple est de ne pas mettre de mot de passe et d'utiliser une 
passkey avec un utilisateur crée spécifiquement sur ta machine.


Benoit SZCZYGIEL


message d'origine-
De: Bernard Schoenacker [bernard.schoenac...@free.fr 
  ]
Pour: Liste Debian [debian-user-french@lists.debian.org 
  ]

Date: Sat, 9 Dec 2017 07:36:59 +0100 (CET)
-



bonjour,


j'ai mis en place pour une personne qui utilise l'informatique cette 
solution :


https://renoirboulanger.com/blog/2012/02/creer-un-tunnel-ssh-inverse
-pour-pouvoir-supporter-a-distance-un-ami-utilisant-linux/

ensuite je souhaiterai mettre le mot de passe dans le script et 
ainsi automatiser
la connection sans que le nat indique l'adresse ip interne et que le 
port

22 soit ouvert (sslh ?) ...

merci pour vos tuyaux

slt
bernard







--
Pierre Malard

  « /La façon de donner vaut mieux que ce que l'on donne /»
                 Pierre Corneille (1606-1684) - Le menteur
   |\      _,,,---,,_
   /,`.-'`'    -.  ;-;;,_
  |,4-  ) )-,_. ,\ (  `'-'
 '---''(_/--'  `-'\_)   πr

perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-.  ;-;;,_:  |,A-  ) 
)-,_. ,\ (  `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"'  `-'"'"'\_): 
24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print'

- --> Ce message n’engage que son auteur <--

Re: Filter logcheck reboot messages?

[Sven Hartge]

Richard Hector  wrote:

> Nobody else uses logcheck? Everyone is fine with how it works?

I use logcheck on all systems and I see no need to change it. In fact, I
*want* the reboot messages and filtering them out would be a regression
for me.

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.

Re: on-screen artifacts (red pixels) at high resolution with Intel HD 630 (Kaby Lake)

[Alexandre Rossi]

> Screenshot [1] looks normal to me, but on screenphoto [2] I clearly see
> red-ish stripes and pink spots in the middle.
>
> Now it looks like your LCD could be faulty not PC hardware\software. Can you
> test it with another LCD monitor, or connect it to TV via HDMI cable if it's
> possible?

The same TV and cable work fine at the same resolution with another PC
and another laptop.
The same TV, cable and same computer work fine if using Windows 10.

So the problem only happens with that PC _AND_ Linux/Xorg.

Alex

Re: Embarrassing security bug in systemd

[Brian]

On Sat 09 Dec 2017 at 10:12:16 +, Joe wrote:

> On Fri, 8 Dec 2017 23:56:44 +
> Brian  wrote:
> 
> > On Fri 08 Dec 2017 at 23:06:00 +, Joe wrote:
> > 
> > > On Fri, 8 Dec 2017 17:12:18 -0500
> > > Cindy-Sue Causey  wrote:
> > >   
> > > > 
> > > > I do remember having to give a password, but I don't remember how
> > > > long ago now. And I have too much open right now to test drive
> > > > whether mine does it or not these days.. :)
> > > >   
> > > As I did the other day. I've tried it now (up-to-date unstable) and
> > > it works for a non-root user.  
> > 
> > Without policykit-1 installed it doesn't; no rebooting or powering
> > off with /sbin/reboot or /sbin/poweroff for a user. CTRL+ALT+DEL
> > from a terminal reboots. That's the same behaviour as sysvinit.
> > 
> 
> Yes, I understand that, the point is that the first installation of
> policykit-1, which I did not explicitly request, did not ask me if I
> wanted non-root users to be able to reboot, or indeed about anything
> else it might control. Not that it matters on any of my machines, I'd
> just like to have been told that it was changing, and given the option
> to keep it as it was had I needed to.

The Terms and Conditions of installing a Debian package include (as
I'm sure you are aware) accepting the Depends: and Recomends: lines.
What is in these lines can be accepted or rejected and, in the case
of Recommends:, adjusted to suit your needs. Installing the package
necessarily involves making an explicit request for other packages.

Being asked about choices on installing policykit would probably have
involved a patch for the package and a debconf notice informing users
about this and other changes over previous system behaviour. Apart
from the notice perhaps getting involved, the option to keep previous
behaviour would be of no importance to new users.

-- 
Brian.

Re: Filter logcheck reboot messages?

[Jeremy Nicoll]

On Sat, 9 Dec 2017, at 01:19, Richard Hector wrote:

> Nobody else uses logcheck?  Everyone is fine with how it works?

Can't say... but having never heard of it I googled it, found my way 
to the project page and its mail-lists, and noticed that there's been
hardly any traffic there for years.

On the other hand, there's a tiny amount of activity shown at its
git repo.  


(I'm not a Debian - or any form of linux - user yet, just lurking and
trying to get a better feel for it.)

-- 
Jeremy Nicoll - my opinions are my own.

Re: connection ssh semi automatique

[Pierre Malard]

Bonjour,

Avez vous regardé un outil comme « autossh » ? Cela fait exactement ce que vous 
suggérez et, avec un échange de clés, tout est transparent.

> Le 9 déc. 2017 à 09:29, amandine SZCZYGIEL Z.elec  a 
> écrit :
> 
> Bonjour,
> Le plus simple est de ne pas mettre de mot de passe et d'utiliser une passkey 
> avec un utilisateur crée spécifiquement sur ta machine.
> 
> Benoit SZCZYGIEL
> 
> 
> message d'origine-
> De: Bernard Schoenacker [bernard.schoenac...@free.fr  ]
> Pour: Liste Debian [debian-user-french@lists.debian.org  ]
> Date: Sat, 9 Dec 2017 07:36:59 +0100 (CET)
> -
> 
> 
>> bonjour,
>> 
>> 
>> j'ai mis en place pour une personne qui utilise l'informatique cette 
>> solution :
>> 
>> https://renoirboulanger.com/blog/2012/02/creer-un-tunnel-ssh-inverse
>> -pour-pouvoir-supporter-a-distance-un-ami-utilisant-linux/
>> 
>> ensuite je souhaiterai mettre le mot de passe dans le script et ainsi 
>> automatiser
>> la connection sans que le nat indique l'adresse ip interne et que le port
>> 22 soit ouvert (sslh ?) ...
>> 
>> merci pour vos tuyaux
>> 
>> slt
>> bernard
>> 
>> 
> 
> 

--
Pierre Malard

  « La façon de donner vaut mieux que ce que l'on donne »
   Pierre Corneille (1606-1684) - Le menteur
   |\  _,,,---,,_
   /,`.-'`'-.  ;-;;,_
  |,4-  ) )-,_. ,\ (  `'-'
 '---''(_/--'  `-'\_)   πr

perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-.  ;-;;,_:  |,A-  ) )-,_. ,\ 
(  `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"'  `-'"'"'\_): 
24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print'
- --> Ce message n’engage que son auteur <--



signature.asc
Description: Message signed with OpenPGP

Re: Embarrassing security bug in systemd

[Joe]

On Fri, 8 Dec 2017 23:56:44 +
Brian  wrote:

> On Fri 08 Dec 2017 at 23:06:00 +, Joe wrote:
> 
> > On Fri, 8 Dec 2017 17:12:18 -0500
> > Cindy-Sue Causey  wrote:
> >   
> > > 
> > > I do remember having to give a password, but I don't remember how
> > > long ago now. And I have too much open right now to test drive
> > > whether mine does it or not these days.. :)
> > >   
> > As I did the other day. I've tried it now (up-to-date unstable) and
> > it works for a non-root user.  
> 
> Without policykit-1 installed it doesn't; no rebooting or powering
> off with /sbin/reboot or /sbin/poweroff for a user. CTRL+ALT+DEL
> from a terminal reboots. That's the same behaviour as sysvinit.
> 

Yes, I understand that, the point is that the first installation of
policykit-1, which I did not explicitly request, did not ask me if I
wanted non-root users to be able to reboot, or indeed about anything
else it might control. Not that it matters on any of my machines, I'd
just like to have been told that it was changing, and given the option
to keep it as it was had I needed to.

-- 
Joe

Re: naviguer dans les répertoires en mode script

[Jean-Marc]

Sat, 09 Dec 2017 05:25:50 +0100
Maxime  écrivait :

> Le vendredi 08 décembre 2017 à 11:25 +0100, Dominique Asselineau a écrit :
> > jérémy prego wrote on Fri, Dec 08, 2017 at 10:17:44AM +0100
> > > bonjour,
> > > cd ~ ou cd # fonctionne ici
> > 
> > Et si on veut revenir au rép. précédemment quitter, quel qu'il soit donc, 
> > 
> > cd -
> 
> Ou la variable $OLDPWD qui fonctionne aussi :
> 
>   cd $OLDPWD

Comme je le disais dans une précédente réponse, le plus simple est d'utiliser 
les commandes popd et pushd.

> 
> -- 
> Maxime.
> PGP : B8D0 6988 5DAC DA7B 7751  FD11 6AF9 C36F 6E55 E3E6
> Ğ1 : 7vAhNi1mAjQZAD9kmioVVaDqcJedAHBXx84Tn5YtArhL


Jean-Marc 


pgpnmNXKEEtNL.pgp
Description: PGP signature

Re: Embarrassing security bug in systemd

[Brian]

On Sat 09 Dec 2017 at 07:52:56 +, Jonathan Dowland wrote:

> On Fri, Dec 08, 2017 at 07:57:03PM +, Brian wrote:
> > > That's a good point.
> > 
> > Not really. systemd doesn't stop providing a single place to define a
> > consistent policy because a set of users do not use it.
> 
> That's not the point I thought was good: the point is, in Debian,
> systemd is optional. As an Operating System, consistency is a good
> thing, and so if we have a consistent policy for anything, it would be
> nice if that was not dependent on optional software. On the other hand,
> nobody has put together an alternative to achieve the same thing, and we
> are all volunteers.

Consistencey can be achieved by not installing policykit. The OP appears
to have chosen the wrong target.

> > A bug report against the release notes with a patch is always worth a
> > try.
> 
> The relevant release notes would be the ones for the release that
> introduced systemd which has been and gone.

Nothing is irreversible. A proposed erratum, then.

-- 
Brian.

Re: Embarrassing security bug in systemd

[Joe]

On Sat, 09 Dec 2017 01:46:59 +
Mark Fletcher  wrote:

> The OP has never been seen again since the original post. Just
> sayin’...
> 
>

Because he accidentally discovered a new feature, thought it was a bug,
and was immediately corrected. End of story.

We've been discussing the 'accidentally'.

-- 
Joe

Re: Embarrassing security bug in systemd

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, Dec 08, 2017 at 05:04:51PM -0600, John Hasler wrote:
> tomas writes:
> > Not a fan of systemd here (have outed myself this way clearly enough,
> > I think), but systemd is pretty well documented, for sure.
> 
> Is the Debian default configuration of Systemd also well documented?

This enough for you?

  https://wiki.debian.org/systemd

Try a search on that wiki:

  
https://wiki.debian.org/FrontPage?action=fullsearch=180=systemd=Titles

or similar. No, lack of documentation is not something
you could blame onto systemd (or its surroundings).

Cheers
- -- t
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlorn+wACgkQBcgs9XrR2kaUVACfRP1XGRnK4J4IYKCT+rP6K8JA
XcIAn1d+xRcIhp1VSVA4A6LcZEU/t1W9
=S08x
-END PGP SIGNATURE-

Re: connection ssh semi automatique

[amandine SZCZYGIEL Z.elec]

Bonjour,
Le plus simple est de ne pas mettre de mot de passe et d'utiliser une  
passkey avec un utilisateur crée spécifiquement sur ta machine.


Benoit SZCZYGIEL


message d'origine-
De: Bernard Schoenacker [bernard.schoenac...@free.fr  ]
Pour: Liste Debian [debian-user-french@lists.debian.org  ]
Date: Sat, 9 Dec 2017 07:36:59 +0100 (CET)
-



bonjour,


j'ai mis en place pour une personne qui utilise l'informatique cette  
solution :


https://renoirboulanger.com/blog/2012/02/creer-un-tunnel-ssh-inverse
-pour-pouvoir-supporter-a-distance-un-ami-utilisant-linux/

ensuite je souhaiterai mettre le mot de passe dans le script et  
ainsi automatiser

la connection sans que le nat indique l'adresse ip interne et que le port
22 soit ouvert (sslh ?) ...

merci pour vos tuyaux

slt
bernard

Re: Embarrassing security bug in systemd

[Jonathan Dowland]

On Sat, Dec 09, 2017 at 01:30:17AM +, Glenn English wrote:

Even if there's an error in the release note? Less than optimal way to
run a train.


Errors and omissions are different things. I'm not responsible for
release notes but I suspect if there was something that was glaringly
false, it *could* be changed. Let me know if you find one.

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Re: Embarrassing security bug in systemd

[Jonathan Dowland]

On Fri, Dec 08, 2017 at 03:31:54PM -0500, Gene Heskett wrote:

On Friday 08 December 2017 14:26:41 Jonathan Dowland wrote:

No objection there, and I agree that the release notes should probably
have covered the policy changes. That ship has now sailed
unfortunately.


So now, no effort will ever be made to fix the man pages. Hell of a way
to run a train.


Release notes and manual pages are completely different things. The
systemd manual pages are pretty good, IMHO. But If you'd like to point
out specific omissions, they might get fixed.

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Re: Embarrassing security bug in systemd

[Jonathan Dowland]

On Fri, Dec 08, 2017 at 07:57:03PM +, Brian wrote:

That's a good point.


Not really. systemd doesn't stop providing a single place to define a
consistent policy because a set of users do not use it.


That's not the point I thought was good: the point is, in Debian,
systemd is optional. As an Operating System, consistency is a good
thing, and so if we have a consistent policy for anything, it would be
nice if that was not dependent on optional software. On the other hand, 
nobody has put together an alternative to achieve the same thing, and we

are all volunteers.


A bug report against the release notes with a patch is always worth a
try.


The relevant release notes would be the ones for the release that
introduced systemd which has been and gone.

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.