DHCP failure (was Re: Unidentified subject!)

[Dan Ritter]

On Wed, Sep 28, 2016 at 03:30:04PM -0700, hol...@cox.net wrote:
> Clean install of deb8 (jessie)on my Thinkpad T4220i laptop. went well
> except for the fact that the network configuration
> with DCP failed.
> 
> I was given 3 options.
> 1) try it again. This was hope over experience.
> 2) configure manually. Great if I had the first inkling how. I'm a
> complete neophyte when it
>comes to networking.
> 3) continue without configuring a network. The only one that would let
> me continue the
>installation.
> 
> I have a functioning desktop pc so I compred some files w/ the laptop.
> 
> /etc/networks was identical as was /etc/network/interfaces (from what I
> could see) and /etc/NetworkManager.
> 
> I looked at "man interfaces" but quickly got in over my head.
> 
> Multiple installs resulted in the same failure.

Normally, you would have a DHCP server, perhaps included in your
router, which would hand out local IP addresses.

Possible cause 1: you don't. 

Possible cause 2: you do, but it is full or configured not to
give this machine an IP.

Most likely cause: underlying networking is not working right.

Ethernet or wifi?

What does "ip l" tell you? "ip a", too.

-dsr-

missing subject

[Bob Holtzman]

Sorry. Hit the send key too soon. Subject should have been network
configuration.

-- 
Bob Holtzman
A man is a man who will fight with a sword or
conquer Mt. Everest in snow. But the bravest of all
owns a '34 Ford and tries for six thousand in low.

Unidentified subject!

[holtzm]

Clean install of deb8 (jessie)on my Thinkpad T4220i laptop. went well
except for the fact that the network configuration
with DCP failed.

I was given 3 options.
1) try it again. This was hope over experience.
2) configure manually. Great if I had the first inkling how. I'm a
complete neophyte when it
   comes to networking.
3) continue without configuring a network. The only one that would let
me continue the
   installation.

I have a functioning desktop pc so I compred some files w/ the laptop.

/etc/networks was identical as was /etc/network/interfaces (from what I
could see) and /etc/NetworkManager.

I looked at "man interfaces" but quickly got in over my head.

Multiple installs resulted in the same failure.

Right now I feel like I'm drowning and could sure use a pointer or six.

If any more information is required (and I'm sure it is) let me know.

-- 
Bob Holtzman
A man is a man who will fight with a sword or
conquer Mt. Everest in snow. But the bravest of all
owns a '34 Ford and tries for six thousand in low.

Re: WARNING! New Perl/Perl-base upgrade removes 141 Sid/Unstable packages

[Don Armstrong]

On Wed, 28 Sep 2016, Miles Fidelman wrote:
> As a general rule, I find that using Debian packaging for perl makes
> absolutely no sense - and often problematic.

There is pretty much a 1:1 mapping from CPAN packages to Debian
packages. The only thing which is even remotely complicated is how perl
itself is packaged, because many things link against perl, and when the
perl API and/or ABI change, they all have to be rebuilt.

> Perl has its own ecosystem (cpan) that does an incredibly good job of
> packaging, updating, and dependency management. Mixing and matching
> that with Debian packaging, and expecting packagers to keep up with
> updates to lots of different perl modules, is just a recipe for
> disaster.

We have a perl team which handles this pretty effectively, actually, and
has tools to automate the updates to hundreds of CPAN modules.

It also works much better than CPAN when you're deploying to production,
as you can:
 + reproduce the production environment
 + don't have to deal with having compilers, etc. in production,
 + have security support
 + have long-term support

and indeed, if you need something from CPAN which isn't packaged, that's
literally just a dh-make-perl --cpan Foo::Bar; away.

-- 
Don Armstrong  https://www.donarmstrong.com

If you wish to strive for peace of soul, then believe; if you wish to
be a devotee of truth, then inquire.
 -- Friedrich Nietzsche

Re: WARNING! New Perl/Perl-base upgrade removes 141 Sid/Unstable packages

[Sven Hartge]

Andre Majorel  wrote:
> On 2016-09-28 10:46 -0500, John Hasler wrote:
>> Vincent Lefevre writes:

>>> Things like that should not happen. But this is not a bug in the
>>> perl packages. This is a misfeature of apt / aptitude, which want to
>>> remove packages instead of holding the new packages (well, AFAIK,
>>> aptitude has improved, but is still not perfect).

>> Aptitude can't read your mind.  When you tell it to install something
>> it assumes that you mean what you say and proposes solutions to any
>> conflicts based on various heuristics.

> When there's some kind of conflict during a package installation or
> upgrade, the first solutions proposed by aptitude almost invariably
> involve large numbers of package removals. 

There is an option to tune the resolver. I have got the following in my
/etc/apt/apt.conf:

,
| // tweak Aptitude to not suggest removals as first option
| Aptitude::ProblemResolver::SolutionCost "removals";
`

S°

-- 
Sigmentation fault. Core dumped.

Re: WARNING! New Perl/Perl-base upgrade removes 141 Sid/Unstable packages

[Miles Fidelman]

As a general rule, I find that using Debian packaging for perl makes 
absolutely no sense - and often problematic.


Perl has its own ecosystem (cpan) that does an incredibly good job of 
packaging, updating, and dependency management.  Mixing and matching 
that with Debian packaging, and expecting packagers to keep up with 
updates to lots of different perl modules, is just a recipe for disaster.


Far better to install perl manually and use cpan to manage updates and 
installs.



On 9/28/16 4:06 PM, Stefan Monnier wrote:

It doesn't remove anything without your permission.  It proposes
a solution to the problem you present it with.  You can reject that
solution and have it try again.

FWIW, the way it presents the solution makes it hard to see what's
really going on.  More specifically, the list of removed packages does
not distinguish the manually-installed packages from the
automatically-installed ones.

I usually don't care about removing automatically-installed packages,
whereas I rarely want to remove manually-installed packages.


 Stefan


--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

Re: WARNING! New Perl/Perl-base upgrade removes 141 Sid/Unstable packages

[Stefan Monnier]

> It doesn't remove anything without your permission.  It proposes
> a solution to the problem you present it with.  You can reject that
> solution and have it try again.

FWIW, the way it presents the solution makes it hard to see what's
really going on.  More specifically, the list of removed packages does
not distinguish the manually-installed packages from the
automatically-installed ones.

I usually don't care about removing automatically-installed packages,
whereas I rarely want to remove manually-installed packages.


Stefan

Re: WARNING! New Perl/Perl-base upgrade removes 141 Sid/Unstable packages

[John Hasler]

Andre Majorel writes:
> If aptitude got it wrong half the time, it might be for want of
> reading minds. But in my experience it gets it consistently
> wrong. Suggests to me that what it needs is new heuristics.

Patches are always welcome.
-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA

Re: WARNING! New Perl/Perl-base upgrade removes 141 Sid/Unstable packages

[Andre Majorel]

On 2016-09-28 10:46 -0500, John Hasler wrote:
> Vincent Lefevre writes:
> > Things like that should not happen. But this is not a bug in the perl
> > packages. This is a misfeature of apt / aptitude, which want to remove
> > packages instead of holding the new packages (well, AFAIK, aptitude
> > has improved, but is still not perfect).
> 
> Aptitude can't read your mind.  When you tell it to install
> something it assumes that you mean what you say and proposes
> solutions to any conflicts based on various heuristics.

When there's some kind of conflict during a package installation
or upgrade, the first solutions proposed by aptitude almost
invariably involve large numbers of package removals. The
simple solution that upgrades/installs what can be and leaves
the rest alone is usually there but buried under at least three
-- and sometimes tens of -- very disruptive ones.

If aptitude got it wrong half the time, it might be for want of
reading minds. But in my experience it gets it consistently
wrong. Suggests to me that what it needs is new heuristics.

-- 
André Majorel 
Ever got spam through an address harvested from bugs.debian.org ?
Neither have I.

Re: WARNING! New Perl/Perl-base upgrade removes 141 Sid/Unstable packages

[John Hasler]

Vincent Lefevre writes:
> I'm not asking it to read my mind. I just want it not to remove any
> package I have manually installed.

It doesn't remove anything without your permission.  It proposes
a solution to the problem you present it with.  You can reject that
solution and have it try again.

You can also pin packages so that they will never be removed.   If you
do this without fully understanding the consequences you will be sorry.

Also understand that it is not optimized for use with Unstable.
-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA

Re: WARNING! New Perl/Perl-base upgrade removes 141 Sid/Unstable packages

[Sven Hartge]

Vincent Lefevre  wrote:
> On 2016-09-28 10:46:31 -0500, John Hasler wrote:
>> Vincent Lefevre writes:

>>> Things like that should not happen. But this is not a bug in the
>>> perl packages. This is a misfeature of apt / aptitude, which want to
>>> remove packages instead of holding the new packages (well, AFAIK,
>>> aptitude has improved, but is still not perfect).
 
>> Aptitude can't read your mind.

> I'm not asking it to read my mind. I just want it not to remove any
> package I have manually installed.

Sometimes packages change their name or are replaced by different
packages or are just removed without any viable replacement.

If apt/aptitude would hold on to your manually installed packages
forever you would soon end up in a situation where no further upgrades
can take place because all changes, either direct or indirect through
dependencies and conflicts, would violate your constraint of keeping
every manually installed package forever.

And just to remind again: this is Unstable/Sid we are talking about.
Things like this during transitions can and will happen and every user
of Unstable should be prepared to a) recognize such a situation and b)
be able to deal with the situation accordingliy.

That being said: yes, it would be nice if apt/aptitude somehow knew of
running transitions, just like tracker.debian.org knows and factor that
into the decision what to upgrade and what to remove.

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.

Re: Maximal volume size for the client with a NFS v3 mounting

[Andrew M.A. Cater]

On Wed, Sep 28, 2016 at 08:06:53PM +0200, Christian Seiler wrote:
> On 09/28/2016 07:18 PM, Jean-Paul Bouchet wrote:
> > On a Jessie 8.5 system I mount a partition on a NAS server with NFSv3
> > protocol using options "nfs rw,soft" in /etc/fstab.
> > 
> > The size of the volume on the NAS server side has been extended to 20
> > To, but for my Debian system, this extension appears to be limited to
> > 16 To :
> > - The df command gives 16106127360 blocks of 1K
> > - processes trying to write beyond this limit end with error "no
> >   space left on device"
> > 
> > Is the volume size mounted with NFSv3 limited to 16 To on the client
> > side ?
> 
> RFC 1813 (the NFSv3 standard) defines the field for the free
> space in the response of a NFSv3 server to be a 64bit (probably
> unsigned) integer, so that should easily hold more than 16 TiB.
> 
> In your case, the 16 TiB limit you experience seems to be if
> the size is somehow measured in a 32bit field in units of 4 KiB
> blocks. From reading the source code, Linux 3.16 (that comes
> with Jessie) only uses 64bit fields in both the NFS client code
> and the general kernel structures, so I believe you're running
> into a limitation of the NFS server your NAS provides.
> 
> I am not sure though - and I don't have any storage with more
> than 16 TiB lying around to actually test it - so take my
> response as an educated guess based on my read of the kernel
> source code.
> 

It may depend on what filesystem is on your storage - and also whether
it's been resized to fit the underlying storage.

I did come across a filesystem bug a while where e2fsck didn't handle
> 16TB - but that was fixed.

Some other Linux distros might be limited to 16TB per single volume?

Ext4 is potentially Exabyte capable

What set up your NFS volume in the first place?

All best

Andy C



> > Could the version 4 of NFS solve this problem ?
> 
> Possibly; it could be that the NFS4 implementation of your NAS
> is not limited in that way - it could also be that it is. It
> could also be that the NFS server in your NAS doesn't support
> volumes > 16 TiB at all.
> 
> Another possibility could be that your NAS's NFS server supports
> more than 16 TiB just fine, but the underlying filesystem used
> on the NAS only supports up to 16 TiB. (For example, if the NAS
> were to use the old Linux filesystem ReiserFS, that only supports
> volumes up to 16 TiB.) Does the NAS actually show that there's
> that much space free on the filesystem it exports? Or does it
> only see the 20 TiB on the partitioning level? What NAS are you
> using and what software are you running there?
> 
> Regards,
> Christian

Re: WARNING! New Perl/Perl-base upgrade removes 141 Sid/Unstable packages

[Brad Rogers]

On Wed, 28 Sep 2016 19:55:49 +0200
Vincent Lefevre  wrote:

Hello Vincent,

>I'm not asking it to read my mind. I just want it not to
>remove any package I have manually installed.

I don't use aptitude, but if I understand things correctly, you don't
have to accept the first thing offered.  So, reject each option it offers
that doesn't do what you wish.  Eventually, you should be offered a
solution you approve of or can at least live with.

-- 
 Regards  _
 / )   "The blindingly obvious is
/ _)radnever immediately apparent"
This disease is catching
Into The Valley - Skids


pgpvW9NbV1vdZ.pgp
Description: OpenPGP digital signature

Re: WARNING! New Perl/Perl-base upgrade removes 141 Sid/Unstable packages

[Stefan Monnier]

> I'm not asking it to read my mind. I just want it not to
> remove any package I have manually installed.

FWIW, I really wish Debian could upgrade their package tools to follow
a model similar to Nix/Guix.  Basically, I'd like to have a master
configuration file where I list the packages I want to be installed (more
or equivalent to the current notion of "manually installed"), as well as
any other constraints I want to impose (e.g. so as to hold packages)
(and ideally also any constraint I want to ignore, in case some package
comes with a Require with which I disagree).

Then from this the tools can build the set of packages that will be
installed, and then add/remove packages accordingly.


Stefan

Re: Maximal volume size for the client with a NFS v3 mounting

[Christian Seiler]

On 09/28/2016 07:18 PM, Jean-Paul Bouchet wrote:
> On a Jessie 8.5 system I mount a partition on a NAS server with NFSv3
> protocol using options "nfs rw,soft" in /etc/fstab.
> 
> The size of the volume on the NAS server side has been extended to 20
> To, but for my Debian system, this extension appears to be limited to
> 16 To :
> - The df command gives 16106127360 blocks of 1K
> - processes trying to write beyond this limit end with error "no
>   space left on device"
> 
> Is the volume size mounted with NFSv3 limited to 16 To on the client
> side ?

RFC 1813 (the NFSv3 standard) defines the field for the free
space in the response of a NFSv3 server to be a 64bit (probably
unsigned) integer, so that should easily hold more than 16 TiB.

In your case, the 16 TiB limit you experience seems to be if
the size is somehow measured in a 32bit field in units of 4 KiB
blocks. From reading the source code, Linux 3.16 (that comes
with Jessie) only uses 64bit fields in both the NFS client code
and the general kernel structures, so I believe you're running
into a limitation of the NFS server your NAS provides.

I am not sure though - and I don't have any storage with more
than 16 TiB lying around to actually test it - so take my
response as an educated guess based on my read of the kernel
source code.

> Could the version 4 of NFS solve this problem ?

Possibly; it could be that the NFS4 implementation of your NAS
is not limited in that way - it could also be that it is. It
could also be that the NFS server in your NAS doesn't support
volumes > 16 TiB at all.

Another possibility could be that your NAS's NFS server supports
more than 16 TiB just fine, but the underlying filesystem used
on the NAS only supports up to 16 TiB. (For example, if the NAS
were to use the old Linux filesystem ReiserFS, that only supports
volumes up to 16 TiB.) Does the NAS actually show that there's
that much space free on the filesystem it exports? Or does it
only see the 20 TiB on the partitioning level? What NAS are you
using and what software are you running there?

Regards,
Christian

Re: WARNING! New Perl/Perl-base upgrade removes 141 Sid/Unstable packages

[Vincent Lefevre]

On 2016-09-28 10:46:31 -0500, John Hasler wrote:
> Vincent Lefevre writes:
> > Things like that should not happen. But this is not a bug in the perl
> > packages. This is a misfeature of apt / aptitude, which want to remove
> > packages instead of holding the new packages (well, AFAIK, aptitude
> > has improved, but is still not perfect).
> 
> Aptitude can't read your mind.

I'm not asking it to read my mind. I just want it not to
remove any package I have manually installed.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Maximal volume size for the client with a NFS v3 mounting

[Jean-Paul Bouchet]

Hi,

On a Jessie 8.5 system I mount a partition on a NAS server with NFSv3 
protocol using options  "nfs  rw,soft" in /etc/fstab.


The size of the volume on the NAS server side has been extended to 20 
To, but for my Debian system, this extension appears to be limited to 16 
To :

- The df command gives 16106127360 blocks of 1K
- processes trying to write beyond this limit end with error "no space 
left on device"


Is the volume size mounted with NFSv3 limited to 16 To on the client side ?

Could the version 4 of NFS solve this problem ?

Thanks

Jean-Paul

Re: WARNING! New Perl/Perl-base upgrade removes 141 Sid/Unstable packages

[John Hasler]

Vincent Lefevre writes:
> Things like that should not happen. But this is not a bug in the perl
> packages. This is a misfeature of apt / aptitude, which want to remove
> packages instead of holding the new packages (well, AFAIK, aptitude
> has improved, but is still not perfect).

Aptitude can't read your mind.  When you tell it to install something it
assumes that you mean what you say and proposes solutions to any
conflicts based on various heuristics.  You are expected to look over
the proposals and accept or reject them.  With Unstable often the best
solution is to give up on installing that package for now.
-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA

[SOLVED ]Re: Issues with SSH pubkey authentication at remote server

[Stephan Beck]

Hi,

to...@tuxteam.de:
> On Wed, Sep 28, 2016 at 08:36:00AM +, Stephan Beck wrote:
>> Hi Lars,
> 
>> Lars Noodén:
>>> On 09/27/2016 06:07 PM, Stephan Beck wrote:
 Lars Noodén:
> On 09/27/2016 02:02 PM, Stephan Beck wrote:
> Can you tell more about how your login session is started?

 I connect to the "local ssh account" by ssh from my other user account.
>>>
>> [...]
[...]
> Yes. It depends. If you're typically using X as your environment
> (perhaps via some desktop thing: in your case it seems to be LXDE),
> then the first go to is your desktop thing's session management.
> 
> This way all consoles you start will inherit the "coordinates" of
> the agent (in the form of the shell variables SSH_AGEN_PID,
> SSH_AUTH_SOCK and perhaps others I forget). With no desktop environ
> (plain X), X session management (see /etc/X11/XSession.d for
> Debian; there is a 90x11-common_ssh-agent for that). Otherwise
> you have to cook up something in your ~/.profile which looks
> whether there's an agent around and set it up when no. In a nutshell
> 
> 
>   - using a DE: your DE's session management
>   - X without DE: X session management
>   - naked console: .login, .profile (or .bash_profile, .bash_login)

Thanks, Tomás. I'll think about what might be the best solution for me.
Configuring LXDE-Startup applications is maybe the best (and easiest)
solution, whereas adapting ~/.profile I'd be forced to train my console
skills, although that would mean that it only affects this specific user
account.

Cheers,

Stephan


I put SOLVED in the subject line, because the "real" issue, the pubkey
authentication at the remote server is working fine now.

Re: WARNING! New Perl/Perl-base upgrade removes 141 Sid/Unstable packages

[Vincent Lefevre]

On 2016-09-24 15:48:15 +0200, Sven Hartge wrote:
> Cindy-Sue Causey  wrote:
> > Good morning! Just a heads up that upgrading the following two
> > packages attempts to remove 141 unrelated packages in Sid/Unstable
> > this morning:
> 
> > perl 5.24.1~rc3-2
> > perl-base 5.24.1~rc3-2
> 
> > I grab AMD64 packages in case that makes a difference AND I have other
> > larger packages still waiting to be upgraded, as well.A total of
> > almost 400MB the last couple days! Am on dialup and have to be
> > selective about the order in which packages are upgraded in between
> > taking the opportunity to actually participate online.
> 
> > Yes, a bug has been filed, just minutes ago, and only against Perl
> > at this time.
> 
> Why would you think this is a bug? This is just a normal Perl-API
> transition, the packages need to be rebuild against the new perl to be
> compatible.
> 
> This _is_ Unstable after all, things like this happen all the time.

Things like that should not happen. But this is not a bug in the perl
packages. This is a misfeature of apt / aptitude, which want to remove
packages instead of holding the new packages (well, AFAIK, aptitude
has improved, but is still not perfect).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Canon printer minor quibble

[Brian]

On Wed 28 Sep 2016 at 07:43:54 +0900, Mark Fletcher wrote:

> On Tue, Sep 27, 2016 at 10:53:11PM +0100, Brian wrote:
> > 
> > It wasn't cups-calibrate I was really advocating but the trying out of
> > printing a file using the Canon and Gutenprint drivers. Do both give the
> > same outcome?
> 
> Sorry Brian, I think some confusion there due to my phrasing in the 
> original post. There is, to my knowledge, no Canon-supplied Linux CUPS 
> driver for this printer. When I said some variation of "Canon iX6500 
> series driver" in my original post, I was referring to the Gutenprint 
> driver as that is what the Gutenprint driver is called.

https://www.canondrivers.org/canon-pixma-ix6500-series-driver-download/
 
> Now I will be honest, I haven't googled this recently, and don't have 
> time to even now as I am actually supposed to be in the shower and then 
> on my way to work, but I will check later... but at the time I first set 
> this printer up I could not find anything from Canon for Linux for this 
> printer. Language may have been getting in the way at the time, as this 
> particular model number is/was only ever sold in Japan to my knowledge.
> 
> In the very early days Gutenprint didn't have a driver either and I was 
> using a driver with a very approximately similar name which very 
> approximately worked... but in the fullness of time the Gutenprint 
> driver I am using appeared (or I finally saw what was in front of my 
> face, that is also possible) and I am using it now. The darkness of 
> native Linux printing, and the contrast if you will pardon the pun 
> between that and printing from Windows, didn't strike me until some time 
> later when the driver situation had been stable for some time.

A driver came in Gutenprint 5.2.10 (May 2014)

> So to the best of my knowledge I'm using the right driver, all functions 
> certainly work, and the only issue is how dark the images come out, 
> compared to the high quality results I get when I print from Windows.

The driver is marked EXPERIMENTAL, which could be because it hasn't been
extensively tested.

> Incidentally, the printer _does_ come with a driver (and a ton of 
> bloatware) for Windows. On one Windows printer I installed the driver 
> and the bloatware, on the other VM I installed the absolute minimum to 
> get the network printer to install. (and when I say network printer, I 
> mean from Windows' perspective -- this printer is not a network printer 
> as far as it is concerned, there is no ethernet port on it, the only way 
> in is USB). So the bloatware isn't the reason the printer is looking 
> better under Windows, since both VMs can print with better results (and 
> the same as each other).
> 
> So I am being drawn to the conclusion that your comments about the 
> non-existent Canon driver (it being rubbish at colour management) can be 
> applied instead to the Gutenprint driver, hence the way I perked up when 
> you mentioned cups-calibrate. Which I will try the second I get longer 
> than 5 mins in front of my PC.

You should now be able to compare the outputs of the Gutenprint and
Canon drivers. Color management support is done by cups-filters
(completed in Aug 2014) so it will be common to both drivers.

-- 
Brian.

Re: Issues with SSH pubkey authentication at remote server

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, Sep 28, 2016 at 08:36:00AM +, Stephan Beck wrote:
> Hi Lars,
> 
> Lars Noodén:
> > On 09/27/2016 06:07 PM, Stephan Beck wrote:
> >> Lars Noodén:
> >>> On 09/27/2016 02:02 PM, Stephan Beck wrote:
> >>> Can you tell more about how your login session is started?
> >>
> >> I connect to the "local ssh account" by ssh from my other user account.
> > 
> [...]
> > You need a way for your "local ssh account" to start and use an agent.
> > I'm not sure of the optimal way for you.  Perhaps something in .bashrc?
> > Others here know more about the shells than I.
> 
> Or in .profile. But I am not really sure about the exact syntax to use
> (this if/then "thing"). I still have to get familiar with that.
> 
> I just checked in LX Session Configuration that the ssh-agent is
> configured as -->Core applications but disabled in --> Autostart. So
> there is another program/process/script that has to be launching the
> ssh-agent, because I find it twice in the process list when I login to
> my "normal" user account. I'm shivering :-)

Yes. It depends. If you're typically using X as your environment
(perhaps via some desktop thing: in your case it seems to be LXDE),
then the first go to is your desktop thing's session management.

This way all consoles you start will inherit the "coordinates" of
the agent (in the form of the shell variables SSH_AGEN_PID,
SSH_AUTH_SOCK and perhaps others I forget). With no desktop environ
(plain X), X session management (see /etc/X11/XSession.d for
Debian; there is a 90x11-common_ssh-agent for that). Otherwise
you have to cook up something in your ~/.profile which looks
whether there's an agent around and set it up when no. In a nutshell


  - using a DE: your DE's session management
  - X without DE: X session management
  - naked console: .login, .profile (or .bash_profile, .bash_login)

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

iEYEARECAAYFAlfrikAACgkQBcgs9XrR2kbyVwCcDqnECoJHdevg6AXn4Va6TcZO
J4YAnR8vi2TEcBsPNJrm9V2S/TVM6hhz
=wPAD
-END PGP SIGNATURE-

Re: Issues with SSH pubkey authentication at remote server

[Stephan Beck]

Hi Lars,

Lars Noodén:
> On 09/27/2016 06:07 PM, Stephan Beck wrote:
>> Lars Noodén:
>>> On 09/27/2016 02:02 PM, Stephan Beck wrote:
>>> Can you tell more about how your login session is started?
>>
>> I connect to the "local ssh account" by ssh from my other user account.
> 
[...]
> You need a way for your "local ssh account" to start and use an agent.
> I'm not sure of the optimal way for you.  Perhaps something in .bashrc?
> Others here know more about the shells than I.

Or in .profile. But I am not really sure about the exact syntax to use
(this if/then "thing"). I still have to get familiar with that.

I just checked in LX Session Configuration that the ssh-agent is
configured as -->Core applications but disabled in --> Autostart. So
there is another program/process/script that has to be launching the
ssh-agent, because I find it twice in the process list when I login to
my "normal" user account. I'm shivering :-)

I'll keep you informed.

Thanks again.

Stephan