Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #225116 > unrolled thread

Error while trying to install openssh-server on Buster

Back to article view | Back to linux.debian.user

Contents

  Error while trying to install openssh-server on Buster rhkramer <rhkramer.s32@gmail.com> - 2020-07-22 04:10 +0200
    Re: Error while trying to install openssh-server on Buster Andrew Cater <amacater@gmail.com> - 2020-07-22 13:10 +0200
      Resolved (without understanding ;-) (was: Re: Error while trying to install openssh-server on Buster) rhkramer <rhkramer.s32@gmail.com> - 2020-07-22 20:40 +0200
        Re: Resolved (without understanding ;-) (was: Re: Error while trying  to install openssh-server on Buster) Greg Wooledge <wooledg@eeg.ccf.org> - 2020-07-22 21:00 +0200
          Re: Resolved (without understanding ;-) (was: Re: Error while trying to install openssh-server on Buster) rhkramer@gmail.com - 2020-07-22 22:30 +0200
        Re: Resolved (without understanding ; -) (was: Re: Error while trying  to install openssh-server on Buster) David Wright <deblis@lionunicorn.co.uk> - 2020-07-22 21:30 +0200
          Re: Resolved (without understanding ; -) (was: Re: Error while  trying to install openssh-server on Buster) <tomas@tuxteam.de> - 2020-07-23 10:20 +0200
            Re: Resolved (without understanding ; -) (was: Re: Error while  trying to install openssh-server on Buster) David Wright <deblis@lionunicorn.co.uk> - 2020-07-24 01:50 +0200
              Re: Resolved (without understanding ; -) (was: Re: Error while  trying to install openssh-server on Buster) <tomas@tuxteam.de> - 2020-07-24 11:00 +0200
                Re: Resolved (without understanding ; -) (was: Re: Error while  trying to install openssh-server on Buster) Andrei POPESCU <andreimpopescu@gmail.com> - 2020-07-24 11:10 +0200
                  Antipatterns and Handcuffs [was: Re: Resolved (without understanding  ...] <tomas@tuxteam.de> - 2020-07-24 11:30 +0200
    Re: Error while trying to install openssh-server on Buster Greg Wooledge <wooledg@eeg.ccf.org> - 2020-07-22 13:40 +0200
      Re: Error while trying to install openssh-server on Buster Jonathan Dowland <jon+debian-user@dow.land> - 2020-07-22 17:30 +0200
        Re: Error while trying to install openssh-server on Buster Andrei POPESCU <andreimpopescu@gmail.com> - 2020-07-23 12:30 +0200
          slashes in filenames [was Re: Error while trying to install openssh-server  on Buster] The Wanderer <wanderer@fastmail.fm> - 2020-07-24 01:20 +0200
            Re: slashes in filenames [was Re: Error while trying to install openssh-server on Buster] Stefan Monnier <monnier@iro.umontreal.ca> - 2020-07-24 01:30 +0200
            Re: slashes in filenames [was Re: Error while trying to install  openssh-server on Buster] Greg Wooledge <wooledg@eeg.ccf.org> - 2020-07-24 13:50 +0200
              Re: slashes in filenames [was Re: Error while trying to install  openssh-server on Buster] Greg Wooledge <wooledg@eeg.ccf.org> - 2020-07-24 14:00 +0200
                Re: slashes in filenames [was Re: Error while trying to install  openssh-server on Buster] <tomas@tuxteam.de> - 2020-07-24 15:30 +0200
                  Re: slashes in filenames [was Re: Error while trying to install openssh-server  on Buster] The Wanderer <wanderer@fastmail.fm> - 2020-07-24 15:50 +0200
                    Re: slashes in filenames [was Re: Error while trying to install openssh-server  on Buster] The Wanderer <wanderer@fastmail.fm> - 2020-07-24 16:00 +0200
                      Re: slashes in filenames [was Re: Error while trying to install  openssh-server on Buster] <tomas@tuxteam.de> - 2020-07-24 16:10 +0200
                    Re: slashes in filenames [was Re: Error while trying to install  openssh-server on Buster] <tomas@tuxteam.de> - 2020-07-24 16:00 +0200
                    Re: slashes in filenames [was Re: Error while trying to install  openssh-server on Buster] Michael Stone <mstone@debian.org> - 2020-07-24 16:00 +0200
                    Re: slashes in filenames [was Re: Error while trying to install  openssh-server on Buster] Greg Wooledge <wooledg@eeg.ccf.org> - 2020-07-24 16:00 +0200
                      Re: slashes in filenames [was Re: Error while trying to install  openssh-server on Buster] <tomas@tuxteam.de> - 2020-07-24 16:10 +0200
              Re: slashes in filenames [was Re: Error while trying to install openssh-server  on Buster] The Wanderer <wanderer@fastmail.fm> - 2020-07-24 14:00 +0200
          Re: Error while trying to install openssh-server on Buster Jonathan Dowland <jon+debian-user@dow.land> - 2020-07-24 16:10 +0200
            Re: Error while trying to install openssh-server on Buster Andrei POPESCU <andreimpopescu@gmail.com> - 2020-07-24 16:20 +0200
              Re: Error while trying to install openssh-server on Buster <tomas@tuxteam.de> - 2020-07-24 18:00 +0200
                Re: Error while trying to install openssh-server on Buster Andrei POPESCU <andreimpopescu@gmail.com> - 2020-07-24 20:50 +0200
                  Re: Error while trying to install openssh-server on Buster Greg Wooledge <wooledg@eeg.ccf.org> - 2020-07-24 21:20 +0200
                  Re: Error while trying to install openssh-server on Buster <tomas@tuxteam.de> - 2020-07-25 11:40 +0200
      Re: Error while trying to install openssh-server on Buster Anssi Saari <as@sci.fi> - 2020-07-22 20:50 +0200

Page 2 of 2 — ← Prev page 1 [2]

#225190 — Re: slashes in filenames [was Re: Error while trying to install openssh-server on Buster]

[Multipart message — attachments visible in raw view] — view raw

On 2020-07-24 at 09:50, tomas@tuxteam.de wrote:
> 
> On Fri, Jul 24, 2020 at 09:42:24AM -0400, The Wanderer wrote:
> 
>> On 2020-07-24 at 09:22, tomas@tuxteam.de wrote:

>>> Nitpick: the directory entry is the one carrying the name.
>> 
>> I had the impression that even a directory is stored in/as
>> something that is at least analogous to an inode. Is there a
>> different term that's more appropriate for the on-disk structure
>> which holds a directory, vs. 'inode' for the one that holds a
>> file?
> 
> That's right: the directory is at the same time a file, and thus, 
> represented by the inode. But the name itself is in the content of
> the directory, whithin the directory entry.

Since writing that, I've had occasion to remember the term 'dirent',
which I think is more the in-memory representation of a directory than
the on-disk representation, but might be borrow-able for the purpose.

>> It does seem to suggest that, but when I run
>> 
>> $ /sbin/e2fsck /tmp/testfs
>> 
>> on the tiny filesystem created as in my previous mail, it doesn't
>> report finding any problems and seem to change anything.
> 
> Hm. You gave it the -f option? Otherwise, if the file system is
> marked "clean", e2fsck might choose the lazy option :-)

Indeed I hadn't, and you're right, with that I get lengthier output and
the file's timestamp does get updated (which previously it hadn't).
However, when I examine the file with vbindiff afterwards, the slash is
still there.

-- 
   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

[toc] | [prev] | [next] | [standalone]

#225194 — Re: slashes in filenames [was Re: Error while trying to install openssh-server on Buster]

[Multipart message — attachments visible in raw view] — view raw

On Fri, Jul 24, 2020 at 09:56:27AM -0400, The Wanderer wrote:
> On 2020-07-24 at 09:50, tomas@tuxteam.de wrote:

[...]

> Since writing that, I've had occasion to remember the term 'dirent',
> which I think is more the in-memory representation of a directory than
> the on-disk representation, but might be borrow-able for the purpose.

Ah, old memories. Bach and that :-)

> >> It does seem to suggest that, but when I run
> >> 
> >> $ /sbin/e2fsck /tmp/testfs
> >> 
> >> on the tiny filesystem created as in my previous mail, it doesn't
> >> report finding any problems and seem to change anything.
> > 
> > Hm. You gave it the -f option? Otherwise, if the file system is
> > marked "clean", e2fsck might choose the lazy option :-)
> 
> Indeed I hadn't, and you're right, with that I get lengthier output and
> the file's timestamp does get updated (which previously it hadn't).
> However, when I examine the file with vbindiff afterwards, the slash is
> still there.

That's somewhat funny. No time ATM to step with gdb through that :-(

Cheers
-- t

[toc] | [prev] | [next] | [standalone]

#225191 — Re: slashes in filenames [was Re: Error while trying to install openssh-server on Buster]

[Multipart message — attachments visible in raw view] — view raw

On Fri, Jul 24, 2020 at 09:42:24AM -0400, The Wanderer wrote:
> On 2020-07-24 at 09:22, tomas@tuxteam.de wrote:
> 
> > On Fri, Jul 24, 2020 at 07:54:27AM -0400, Greg Wooledge wrote:
> > 
> >> On Fri, Jul 24, 2020 at 07:49:26AM -0400, The Wanderer wrote:
> >> 
> >>> Sounds like a case where directly editing the underlying device,
> >>> to modify inode-or-equivalent contents such that the slash is no
> >>> longer
> >             ^^^^^
> > Nitpick: the directory entry is the one carrying the name.
> 
> I had the impression that even a directory is stored in/as something
> that is at least analogous to an inode. Is there a different term that's
> more appropriate for the on-disk structure which holds a directory, vs.
> 'inode' for the one that holds a file?

That's right: the directory is at the same time a file, and thus,
represented by the inode. But the name itself is in the content
of the directory, whithin the directory entry.

[...]

> It does seem to suggest that, but when I run
> 
> $ /sbin/e2fsck /tmp/testfs
> 
> on the tiny filesystem created as in my previous mail, it doesn't report
> finding any problems and seem to change anything.

Hm. You gave it the -f option? Otherwise, if the file system is marked
"clean", e2fsck might choose the lazy option :-)

Cheers
-- t

[toc] | [prev] | [next] | [standalone]

#225192 — Re: slashes in filenames [was Re: Error while trying to install openssh-server on Buster]

On Fri, Jul 24, 2020 at 09:42:24AM -0400, The Wanderer wrote:
>On 2020-07-24 at 09:22, tomas@tuxteam.de wrote:
>
>> On Fri, Jul 24, 2020 at 07:54:27AM -0400, Greg Wooledge wrote:
>>
>>> On Fri, Jul 24, 2020 at 07:49:26AM -0400, The Wanderer wrote:
>>>
>>>> Sounds like a case where directly editing the underlying device,
>>>> to modify inode-or-equivalent contents such that the slash is no
>>>> longer
>>             ^^^^^
>> Nitpick: the directory entry is the one carrying the name.
>
>I had the impression that even a directory is stored in/as something
>that is at least analogous to an inode. Is there a different term that's
>more appropriate for the on-disk structure which holds a directory, vs.
>'inode' for the one that holds a file?

In traditional unix filesystems there are inodes that contain 
directory entries, and directory entries consist of a reference to a 
data inode, the filename, the type of the thing the entry is pointing 
to, and some other metadata. To change a filename you'd edit the 
appropriate directory entry.

[toc] | [prev] | [next] | [standalone]

#225193 — Re: slashes in filenames [was Re: Error while trying to install openssh-server on Buster]

On Fri, Jul 24, 2020 at 09:42:24AM -0400, The Wanderer wrote:
> On 2020-07-24 at 09:22, tomas@tuxteam.de wrote:
> 
> > On Fri, Jul 24, 2020 at 07:54:27AM -0400, Greg Wooledge wrote:
> > 
> >> On Fri, Jul 24, 2020 at 07:49:26AM -0400, The Wanderer wrote:
> >> 
> >>> Sounds like a case where directly editing the underlying device,
> >>> to modify inode-or-equivalent contents such that the slash is no
> >>> longer
> >             ^^^^^
> > Nitpick: the directory entry is the one carrying the name.
> 
> I had the impression that even a directory is stored in/as something
> that is at least analogous to an inode. Is there a different term that's
> more appropriate for the on-disk structure which holds a directory, vs.
> 'inode' for the one that holds a file?

I don't know of any specific term for a directory's physical
manifestation, other than "directory".

In the olden days, a directory was basically a series of 16-byte
records (14 bytes for the filename, 2 bytes for the inode number),
repeated as necessary.  You used to be able to cat a directory and
see this.  Under current Debian systems, we've lost this ability,
which makes me sad.  The kernel and libc have conspired to hide the
contents of the directory from view, by making it an error to try
to read one using standard read(2) calls.

[toc] | [prev] | [next] | [standalone]

#225195 — Re: slashes in filenames [was Re: Error while trying to install openssh-server on Buster]

[Multipart message — attachments visible in raw view] — view raw

On Fri, Jul 24, 2020 at 09:52:29AM -0400, Greg Wooledge wrote:

[...]

> I don't know of any specific term for a directory's physical
> manifestation, other than "directory".
> 
> In the olden days, a directory was basically a series of 16-byte
> records (14 bytes for the filename, 2 bytes for the inode number),
> repeated as necessary.

...and those are the directory entries. In olden days, a directory
was much more of a file than these days. You could create a hard
link to it, which could cause some hilarity, because now the file
system tree could have cycles...

Ah, the olden days :-)

Cheers
-- t

[toc] | [prev] | [next] | [standalone]

#225186 — Re: slashes in filenames [was Re: Error while trying to install openssh-server on Buster]

[Multipart message — attachments visible in raw view] — view raw

On 2020-07-24 at 07:45, Greg Wooledge wrote:

> On Thu, Jul 23, 2020 at 07:16:06PM -0400, The Wanderer wrote:
> 
>> On 2020-07-23 at 06:26, Andrei POPESCU wrote:
>>> Seriously? Could you please show me how would I create a file on
>>> *nix containing '/' in the name?
>> 
>> It's theoretically possible, but AFAIK basically nothing would
>> support it or work properly with it.
>> 
>> The only ways I can think of to do it that I wouldn't expect to be 
>> prohibited by the intermediary layers involved (such as the C
>> standard library) would be A: direct file I/O not involving a
>> library (which I'd guess would probably need to be written in
>> architecture-specific ASM), and B: opening the device underlying
>> the filesystem in a hex editor or similar and modifying the stored
>> data in the inode.
> 
> The main way that one gets a filename containing a '/' character in 
> real life is by discovering a bug somewhere.
> 
> I've personally seen it once, on an old HP-UX system that was acting 
> as an NFS server for some Mac clients (long before Mac OS X).
> Apparently the NFS server allowed the clients to create filenames
> with slashes in them, since that's legal on Mac OS 9 and earlier.
> Once such a file was created on the server, you couldn't do
> *anything* to it.  You couldn't delete it, or rename it, or open it.
> The only thing you could do was move out all of the other files in
> the same directory, then rename the directory that it's in to
> something like "xxx_radioactive_waste".  Then recreate the original
> directory, and move all the other files back into it.

Sounds like a case where directly editing the underlying device, to
modify inode-or-equivalent contents such that the slash is no longer
there, might even be *advisable*.

I've seen enough random filename bit-flips in my time that I wouldn't be
surprised if it sometimes happened by simple "routine" filesystem
corruption.

-- 
   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

[toc] | [prev] | [next] | [standalone]

#225196

On Thu, Jul 23, 2020 at 01:26:50PM +0300, Andrei POPESCU wrote:
>Seriously?

Yes seriously. This is a pain point that could be avoided. I'm not a
systemd hater. I do some quite advanced things with it. But I don't
think it's above criticism, and this is an area I feel is worthy of
criticism.

>Could you please show me how would I create a file on *nix
>containing '/' in the name?

The presumption here is that unit names must be stored in files matching 
their name. That's a design choice.

>> and also to map all mounts to units.
>
>What's wrong with that?

As I point out in the rest of my mail, it's a combination of both
decisions that results in some seriously unfriendly unit names.

>> '/' gets remapped to '-', which is otherwise
>> forbidden.
>
>Using '-' to mean '/' allows mount units to have friendly names like
>media-data.mount (the mount unit must be named according to the mount
>point).

'-' is too commonly used in paths IMHO, to have been a good choice.
dev-disk-by\x2duuid-e0eed9b6\x2d03f1\x2d41ed\x2d80a4\x2dc7cc4ff013c3.device
is anything but friendly, and I have many such unit names that I
reference as dependencies of others etc.

The delimiter need not have been one character: a two character
delimiter could have significantly decrease the need for escaping and
remained legible. Even '--'.

>I will argue that UUIDs are not really meant for human consumption
>anyway, so the damage done is reduced.

UUIDs are just one thing that expose this. the "by-uuid" part of the
path there also needs escaping, as does "by-label"; any labels that
happen to use '-', or VG or LV group names, etc.

> There is also 'systemd-escape' to help with conversions.

I didn't know about systemd-escape, thanks: that's a help, but I still
feel that if some of the design decisions had been different, some pain
could be avoided.




-- 
Please do not CC me, I am subscribed to the list.

👱🏻	Jonathan Dowland
✎	 jmtd@debian.org
🔗	https://jmtd.net

[toc] | [prev] | [next] | [standalone]

#225197

[Multipart message — attachments visible in raw view] — view raw

On Vi, 24 iul 20, 15:00:32, Jonathan Dowland wrote:
> On Thu, Jul 23, 2020 at 01:26:50PM +0300, Andrei POPESCU wrote:
> > Seriously?
> 
> Yes seriously. This is a pain point that could be avoided. I'm not a
> systemd hater. I do some quite advanced things with it. But I don't
> think it's above criticism, and this is an area I feel is worthy of
> criticism.

I was referring to your statement

    "Unfortunately Systemd decided to forbid '/' in unit names,"

Not everything is systemd's fault :)

(not that it doesn't have its fair share of bugs, peculiarities, etc.)

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#225200

[Multipart message — attachments visible in raw view] — view raw

On Fri, Jul 24, 2020 at 05:18:24PM +0300, Andrei POPESCU wrote:
> On Vi, 24 iul 20, 15:00:32, Jonathan Dowland wrote:
> > On Thu, Jul 23, 2020 at 01:26:50PM +0300, Andrei POPESCU wrote:
> > > Seriously?
> > 
> > Yes seriously. This is a pain point that could be avoided. I'm not a
> > systemd hater. I do some quite advanced things with it. But I don't
> > think it's above criticism, and this is an area I feel is worthy of
> > criticism.
> 
> I was referring to your statement
> 
>     "Unfortunately Systemd decided to forbid '/' in unit names,"
> 
> Not everything is systemd's fault :)

You mean because unit names gotta be file names and those can't have
a slash in them?

Well, git's branch names are file names too -- and if you create a
branch "foo/bar" (I do that all the time), that makes a directory
"foo" with a file "bar" in it (of course, if you have a tag "foo"
already, you can't add one "foo/bar" -- this would be fixable, too).

I'd like to know what are the factors in a project's "personality"
which lead to such different outcomes.

Cheers
-- t

[toc] | [prev] | [next] | [standalone]

#225210

[Multipart message — attachments visible in raw view] — view raw

On Vi, 24 iul 20, 17:53:53, tomas@tuxteam.de wrote:
> On Fri, Jul 24, 2020 at 05:18:24PM +0300, Andrei POPESCU wrote:
> > On Vi, 24 iul 20, 15:00:32, Jonathan Dowland wrote:
> > > On Thu, Jul 23, 2020 at 01:26:50PM +0300, Andrei POPESCU wrote:
> > > > Seriously?
> > > 
> > > Yes seriously. This is a pain point that could be avoided. I'm not a
> > > systemd hater. I do some quite advanced things with it. But I don't
> > > think it's above criticism, and this is an area I feel is worthy of
> > > criticism.
> > 
> > I was referring to your statement
> > 
> >     "Unfortunately Systemd decided to forbid '/' in unit names,"
> > 
> > Not everything is systemd's fault :)
> 
> You mean because unit names gotta be file names and those can't have
> a slash in them?
 
Yes.

> Well, git's branch names are file names too -- and if you create a
> branch "foo/bar" (I do that all the time), that makes a directory
> "foo" with a file "bar" in it (of course, if you have a tag "foo"
> already, you can't add one "foo/bar" -- this would be fixable, too).

Aren't those files an internal implementation detail? Most users won't 
ever need to interact with those files or even be aware of their 
existence.

> I'd like to know what are the factors in a project's "personality"
> which lead to such different outcomes.

This looks to me very much like comparing apples and oranges.

Besides, it's easier to find flaws in the design after the fact then to 
foresee all possible ramifications in advance.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#225218

On Fri, Jul 24, 2020 at 09:49:04PM +0300, Andrei POPESCU wrote:
> Aren't those files an internal implementation detail? Most users won't 
> ever need to interact with those files or even be aware of their 
> existence.

The whole design is built around "you can do this with systemctl commands,
or by manually changing symlinks around".  The files are directly exposed
to end users, and documented as such.

(I imagine that a big part of the reasoning behind this was to ease
the transition for sysv-rc users, who are/were accustomed to manipulating
symlinks in /etc/rc*.d/ directories to enable and disable services.)

>From systemctl(1):

       enable UNIT..., enable PATH...
           Enable one or more units or unit instances. This will create a set
           of symlinks, as encoded in the "[Install]" sections of the
           indicated unit files. After the symlinks have been created, the
           system manager configuration is reloaded (in a way equivalent to
           daemon-reload), in order to ensure the changes are taken into
           account immediately.

And so on.  I believe there was some page on 0pointer.de that talked
more about this, but damned if I can find it right now....

[toc] | [prev] | [next] | [standalone]

#225239

[Multipart message — attachments visible in raw view] — view raw

On Fri, Jul 24, 2020 at 09:49:04PM +0300, Andrei POPESCU wrote:
> On Vi, 24 iul 20, 17:53:53, tomas@tuxteam.de wrote:

[...]

> Aren't those files an internal implementation detail? Most users won't 
> ever need to interact with those files or even be aware of their 
> existence.

Strictly speaking, yes. Sometimes, thinks leak through the abstraction
layer, sometimes they don't.

Some designs seem to take this into account (Serendipity? Sheer luck?
Wisdom? No idea) -- and they just don't break when things happen, but
kind of elegantly flow around the problem, perhaps even acquiring a
new level of beauty and symmetry. Some other just break. Or grow into
ugly monsters.

This is something I've watched at work. Sometimes I build something
for a customer, and (s)he comes back two years later and asks me "could
you...?". Sometimes, I go "uh...". Just sometimes it's "YES!". Then
I realize that I got the design "right" in the first place. Somehow
I succeeded in modeling the customer's unspoken needs correctly.

Yes, somewhat philosophical. Perhaps the problems of old age :)

> This looks to me very much like comparing apples and oranges.

It's both fruit, ain't it? And it's abstractions we delve in, our
very tissue.

> Besides, it's easier to find flaws in the design after the fact then to 
> foresee all possible ramifications in advance.

Yes.

Cheers
-- t

[toc] | [prev] | [next] | [standalone]

#225131

Greg Wooledge <wooledg@eeg.ccf.org> writes:

> unicorn:~$ systemctl status -.mount
> systemctl: invalid option -- '.'
> Hint: to specify units starting with a dash, use "--":
>       systemctl [OPTIONS...] {COMMAND} -- -.mount ...
> unicorn:~$ systemctl status -- -.mount
> ● -.mount - /
>    Loaded: loaded (/etc/fstab; generated)
>    Active: active (mounted) since Sun 2020-07-19 22:05:16 EDT; 2 days ago
>     Where: /
>      What: /dev/sda7
>      Docs: man:fstab(5)
>            man:systemd-fstab-generator(8)
>
>
> Apparently this unit refers to the root file system.  I have no idea
> why it's masked for you, but that's where I'd start looking.

This actually happened to me recently too. I have no idea why and I
couldn't unmask it either but after a reboot things were normal again.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.debian.user

csiph-web