Re: [Dng] I used Devuan's debootstrap and installed Devuan. :)

[Anto]

On 04/05/15 02:47, David Hare wrote:

On 03/05/15 21:24, Anto wrote:


On 03/05/15 06:31, Edward Bartolo wrote:

The command I used:
debootstrap --arch amd64  jessie  /mnt/sda8
http://packages.devuan.org/merged

/mnt/sda8 is the partition where Devuan was installed.

I will now start testing Devuan.


Hello Edward,

I also tried the installation from that Devuan merged repository using
the same debootstrap command line options. The ones you used actually
also pull libsystemd0, systemd and systemd-sysv. Perhaps you expect less
restrictions on systemd components in Devuan.

As for me, I think I have to wait a little bit longer until the Devuan
merged repository can provide more "cleaner" packages. I initially tried
to use the following debootstrap options.

debootstrap --arch=amd64 --include
linux-image-amd64,grub-pc,locales,console-setup,ssh
--exclude=libsystemd0,systemd,systemd-sysv,init-system-helpers jessie
/tmp/sda1 http://packages.devuan.org/merged

And I got below messages:

W: Failure while configuring base packages.  This will be re-attempted
up to five times.
W: See /tmp/sda1/debootstrap/debootstrap.log for details (possibly the
package openssh-server is at fault)

The failure on openssh-server is due to the exclusion of
init-system-helpers because I don't get those messages when I removed
init-system-helpers from the exclusion list.

When I didn't include ssh I got below messages, which is also due to the
exclusion of init-system-helpers.

W: Failure while configuring base packages.  This will be re-attempted
up to five times.
W: See /tmp/sda1/debootstrap/debootstrap.log for details (possibly the
package cron is at fault)

When I had a look on the sources on that Devuan merged repository, I
didn't see init-system-helpers on the debian/control files of both
openssh-server and cron. Perhaps their dependencies are the ones which
require init-system-helpers.

Cheers,

Anto




Unfortunately (for the moment) you will need to enable 3rd-party repos 
to build a fully-functional system with a (xfxe4) DE:


deb http://angband.pl/debian/ nosystemd main
deb http://exegnulinux.net/nosystemd/ jessie main

The sooner that is no longer necessary the better.

You will also need to (immediately after debootstrap in a chroot):

cat << EOF > /etc/apt/preferences.d/01systemd

Package: *systemd*
Pin: origin ""
Pin-Priority: -1

EOF

cat << EOF > /etc/apt/apt.conf.d/01norecommends

APT::Install-Recommends "0";
APT::Install-Suggests "0";

EOF

else when you run apt-get in the chroot *systemd* *will* get it's 
claws in. The "recommends" only will make sure (xfce at least).


I have tested this multiple times in recent days.

Without that you may not be able to shutdown, reboot, suspend, handle 
removables...


D



Thanks David,

I am quite aware of everything that you wrote. We discussed that on 
another threads in this mailing list, didn't we?


What I was not aware of is that there is already a merged Devuan 
repository. So I can pull packages from Devuan repository instead of 
mixed ones, even a lot of packages are still coming from Debian. But I 
think it is a good enough for me to have the baseline image for testing 
purpose. For that, I removed init-system-helpers from my debootstrap 
exclusion list to be able complete the installation. After that, I 
purged init-system-helpers which forced me to remove cron, logrotate, 
openssh-server, rsyslog, and ssh packages. I then dumped the whole 
/dev/sda (8GB SATA SSD) into an image file as my initial Devuan testing 
baseline. I think I need to buy a smaller SATA SSD to have the image 
switching into/from the backup hard disk faster.


I am not a programmer, but I will try to have a look on source packages 
of cron, logrotate, openssh-server, rsyslog, and ssh. Then I will try to 
remove the soft-dependencies to systemd components, especially 
init-system-helpers, and re-compile them. I don't have any experience at 
all in Debian packaging. I usually just re-compile packages from Debian 
source to match my OS environment. Maybe that would be useful for Devuan 
if I could submit patches. If not, at least I will get the set of 
packages that I want to have on my PC.


Cheers,

Anto

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] [dng] vdev status updates

[Joerg Reisenweber]

On Sun 03 May 2015 15:09:49 Hendrik Boom wrote:
> files are identified *only* by metadata.  Has anyone  ever 
> tried something like this?

I guess tracker  and the way it's 
used by some apps / OS to locate data 
 
 
 - in meego (N9) even for storing 
email and SMS afaik - would qualify as another shadow "file system" which is 
completely agnostic of actual FQN/path. 

Failwhale by concept.

/j



signature.asc
Description: This is a digitally signed message part.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] still failing to install Devuan through debootstrap

[Daniel Reurich]

On 03/05/15 11:29, James Powell wrote:

Has there been any inkling yet of a Devuan iso or bootdisk that we can
unpack something similar to a Gentoo-like stage3 tarball that needs
minimal configuring?


I'm working on it.


--
Daniel Reurich
Centurion Computer Technology (2005) Ltd.
021 797 722
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] Financial report, 1st trimester 2015

[e1]

> Il giorno 04/mag/2015, alle ore 00:47, Jaromil  ha scritto:
> 
> Expect soon more news, certainly we aren't lacking facts to report..
> just a matter of time before we manage to round up on achievements and
> make a proper press release.

Can’t wait :)

Gianluca Zamagni
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] Financial report, 1st trimester 2015

[JeremyBekka C]

>All in all, development is mature enough to produce nightly builds of a
beta
>and have a debootstrap and repository ready for testing by the a larger
public
>meanwhile, its all just a matter of time for the setup of some more public
>infrastructure.  Meanwhile, the VUAs salute all the pioneers on this list
who
>are already happily experimenting and reporting their experiences!

>ciao


Thanks for the update! It is great to see all the progress being made.

I was wondering if there is a set of instructions that would explain how to
build the current version of Devuan. I tried getting the original alpha
working in vagrant without success. I have also seen others posting about
how they got Devuan running on their computers, but I don't quite
understand how to follow the steps they took.

Thanks,

Jeremy
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] [dng] vdev status updates

[Peter Olson]

> On May 3, 2015 at 3:09 PM Hendrik Boom  wrote:
> 
> On Sun, May 03, 2015 at 06:37:06PM +0200, Joerg Reisenweber wrote:
> 
> > Even in your dream distro without any path, don't tell me you won't *have*
> > *to* come up with another concept for attaching meta info alternative to
> > path
> > names, and then you need to update that instead of "moving files"
> 
> Taken to an extreme, that might even be a useful way of running a
> computer -- files are identified *only* by metadata.  Has anyone  ever
> tried something like this?

The BeOS file system used a database-centric approach that might qualify.
 Here's a starting point if you are interested in learning more about it:

http://arstechnica.com/information-technology/2010/06/02/the-beos-filesystem/

Peter Olson
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] I used Devuan's debootstrap and installed Devuan. :)

[David Hare]

On 03/05/15 21:24, Anto wrote:


On 03/05/15 06:31, Edward Bartolo wrote:

The command I used:
debootstrap --arch amd64  jessie  /mnt/sda8
http://packages.devuan.org/merged

/mnt/sda8 is the partition where Devuan was installed.

I will now start testing Devuan.


Hello Edward,

I also tried the installation from that Devuan merged repository using
the same debootstrap command line options. The ones you used actually
also pull libsystemd0, systemd and systemd-sysv. Perhaps you expect less
restrictions on systemd components in Devuan.

As for me, I think I have to wait a little bit longer until the Devuan
merged repository can provide more "cleaner" packages. I initially tried
to use the following debootstrap options.

debootstrap --arch=amd64 --include
linux-image-amd64,grub-pc,locales,console-setup,ssh
--exclude=libsystemd0,systemd,systemd-sysv,init-system-helpers jessie
/tmp/sda1 http://packages.devuan.org/merged

And I got below messages:

W: Failure while configuring base packages.  This will be re-attempted
up to five times.
W: See /tmp/sda1/debootstrap/debootstrap.log for details (possibly the
package openssh-server is at fault)

The failure on openssh-server is due to the exclusion of
init-system-helpers because I don't get those messages when I removed
init-system-helpers from the exclusion list.

When I didn't include ssh I got below messages, which is also due to the
exclusion of init-system-helpers.

W: Failure while configuring base packages.  This will be re-attempted
up to five times.
W: See /tmp/sda1/debootstrap/debootstrap.log for details (possibly the
package cron is at fault)

When I had a look on the sources on that Devuan merged repository, I
didn't see init-system-helpers on the debian/control files of both
openssh-server and cron. Perhaps their dependencies are the ones which
require init-system-helpers.

Cheers,

Anto




Unfortunately (for the moment) you will need to enable 3rd-party repos 
to build a fully-functional system with a (xfxe4) DE:


deb http://angband.pl/debian/ nosystemd main
deb http://exegnulinux.net/nosystemd/ jessie main

The sooner that is no longer necessary the better.

You will also need to (immediately after debootstrap in a chroot):

cat << EOF > /etc/apt/preferences.d/01systemd

Package: *systemd*
Pin: origin ""
Pin-Priority: -1

EOF

cat << EOF > /etc/apt/apt.conf.d/01norecommends

APT::Install-Recommends "0";
APT::Install-Suggests "0";

EOF

else when you run apt-get in the chroot *systemd* *will* get it's claws 
in. The "recommends" only will make sure (xfce at least).


I have tested this multiple times in recent days.

Without that you may not be able to shutdown, reboot, suspend, handle 
removables...


D














___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[Dng] Financial report, 1st trimester 2015

[Jaromil]

re all,

Here is the updated financial report with all recent donations and the
use we are making of them, thanks everyone for your continued support!
http://www.devuan.org/devuan_financial_report_2015.pdf

Expect soon more news, certainly we aren't lacking facts to report..
just a matter of time before we manage to round up on achievements and
make a proper press release.

For the curious people peeking in at this time, here below a round up of
links so far giving hints on where we are:

Our main code repository: https://git.devuan.org/explore

more in detail:

all projects in this group, the base packages we are modifying
https://git.devuan.org/groups/packages-base

the repository software Nextime is writing, amprolla
https://git.devuan.org/devuan-infrastructure/amprolla

the SDK I'm developing, used for package maintainance and to bake isos and vms
https://git.devuan.org/devuan/devuan-sdk

the patches to jenkins-debian-glue by Nextime
https://git.devuan.org/devuan-infrastructure/jenkins-devuan-glue
today included upstream! in case this is used by Debian Jessie
https://github.com/mika/jenkins-debian-glue/blob/master/debian/changelog
then we can officially say that Debian is already using and benefitting
from our development ;^)

the releasebot triggering builds from gitlab to jenkins
https://git.devuan.org/devuan-infrastructure/devuan-releasebot

the Vdev repository by Jude
https://git.devuan.org/pkgs-utopia-substitution/vdev

And a Puppy Linux build profile coming up by Dimkr!

All in all, development is mature enough to produce nightly builds of a beta
and have a debootstrap and repository ready for testing by the a larger public
meanwhile, its all just a matter of time for the setup of some more public
infrastructure.  Meanwhile, the VUAs salute all the pioneers on this list who
are already happily experimenting and reporting their experiences!

ciao


-- 
Jaromil, Dyne.org Free Software Foundry (est. 2000)
We are free to share code and we code to share freedom
Web: https://j.dyne.org Contact: https://j.dyne.org/c.vcf
GPG: 6113 D89C A825 C5CE DD02  C872 73B3 5DA5 4ACB 7D10
Confidential communications: https://keybase.io/jaromil



signature.asc
Description: Digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] [dng] vdev status updates

[Isaac Dunham]

On Sun, May 03, 2015 at 06:37:06PM +0200, Joerg Reisenweber wrote:
> On Sun 03 May 2015 11:15:45 Laurent Bercot wrote:
> > I remember 10ish years ago, mount was actually /sbin/mount.
> > It migrated to /bin at some point, probably, as you say, when the
> > "user" mount option was added. I personally think that moving
> > executables between places is a bad thing, and one of the reasons
> > why I'm not a fan of /sbin.
> 
> Easy!
> in your dream distro you have no directory tree at all and place *all*
> files into root ;-) Never again you have to move a file to the place
> it belongs to (just kidding). Unless you follow that radical approach,
> any sort of meta info no matter which type attached to an item will
> eventually need update when the semantics of the item changes. 

Strawman! (I suppose that you jest.)

This *has* been done before, on a certain *very* minimalist
system that was vaguely and indirectly inspired by *nix.
You just had to make sure that you had the correct "root" filesystem
in the floppy drive.
QDOS/PC-DOS/MS-DOS 1.x is the system referred to. 


Now, regarding Laurent's argument that containers obsolete the concept
of some utilities being useless for users:
One of the major uses for containers is to isolate potentially vulnerable
programs from the rest of the system.
Now, suppose one has a possibly vulnerable webserver in a container with
its own network configuration.
Suppose that someone gets a shell (as whatever user the webserver is
running as); would denying them the ability to modify network state be
useful?

This doesn't establish that /sbin is useful, but the concept of having
a limited set of users be able to utilize a program is likely to remain
relevant even with containers, unless you can set them up so that all
administration takes place externally.

A possible use for /sbin on a non-containerized system is to bind-mount
an empty directory over /sbin/ in a private mount namespace for all
non-administrative users.


Thanks,
Isaac Dunham
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] I used Devuan's debootstrap and installed Devuan. :)

[Anto]

On 03/05/15 06:31, Edward Bartolo wrote:

The command I used:
debootstrap --arch amd64  jessie  /mnt/sda8 http://packages.devuan.org/merged

/mnt/sda8 is the partition where Devuan was installed.

I will now start testing Devuan.


Hello Edward,

I also tried the installation from that Devuan merged repository using 
the same debootstrap command line options. The ones you used actually 
also pull libsystemd0, systemd and systemd-sysv. Perhaps you expect less 
restrictions on systemd components in Devuan.


As for me, I think I have to wait a little bit longer until the Devuan 
merged repository can provide more "cleaner" packages. I initially tried 
to use the following debootstrap options.


debootstrap --arch=amd64 --include 
linux-image-amd64,grub-pc,locales,console-setup,ssh 
--exclude=libsystemd0,systemd,systemd-sysv,init-system-helpers jessie 
/tmp/sda1 http://packages.devuan.org/merged


And I got below messages:

W: Failure while configuring base packages.  This will be re-attempted 
up to five times.
W: See /tmp/sda1/debootstrap/debootstrap.log for details (possibly the 
package openssh-server is at fault)


The failure on openssh-server is due to the exclusion of 
init-system-helpers because I don't get those messages when I removed 
init-system-helpers from the exclusion list.


When I didn't include ssh I got below messages, which is also due to the 
exclusion of init-system-helpers.


W: Failure while configuring base packages.  This will be re-attempted 
up to five times.
W: See /tmp/sda1/debootstrap/debootstrap.log for details (possibly the 
package cron is at fault)


When I had a look on the sources on that Devuan merged repository, I 
didn't see init-system-helpers on the debian/control files of both 
openssh-server and cron. Perhaps their dependencies are the ones which 
require init-system-helpers.


Cheers,

Anto

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] [dng] vdev status updates

[Hendrik Boom]

On Sun, May 03, 2015 at 06:37:06PM +0200, Joerg Reisenweber wrote:

> Even in your dream distro without any path, don't tell me you won't *have* 
> *to* come up with another concept for attaching meta info alternative to path 
> names, and then you need to update that instead of "moving files"

Taken to an extreme, that might even be a useful way of running a 
computer -- files are identified *only* by metadata.  Has anyone  ever 
tried something like this?

-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] [dng] vdev status updates

[Joerg Reisenweber]

On Sun 03 May 2015 11:15:45 Laurent Bercot wrote:
> I remember 10ish years ago, mount was actually /sbin/mount.
> It migrated to /bin at some point, probably, as you say, when the
> "user" mount option was added. I personally think that moving
> executables between places is a bad thing, and one of the reasons
> why I'm not a fan of /sbin.

Easy!
in your dream distro you have no directory tree at all and place *all* files 
into root ;-) Never again you have to move a file to the place it belongs to 
(just kidding). Unless you follow that radical approach, any sort of meta info 
no matter which type attached to an item will eventually need update when the 
semantics of the item changes. 
Even in your dream distro without any path, don't tell me you won't *have* 
*to* come up with another concept for attaching meta info alternative to path 
names, and then you need to update that instead of "moving files"

/j

signature.asc
Description: This is a digitally signed message part.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] Debian Dev: anti-systemd people hate women; thus respectable people should not support anti-systemd stance.

[Nate Bargmann]

* On 2015 02 May 23:47 -0500, Steve Litt wrote:
> On Sat, 2 May 2015 09:03:30 -0700
> "DLL Hell"  wrote:
> 
> 
> > For some reason the men in the Linux community who hate women the
> > most seem to have taken a dislike to systemd. I understand that being
> > “conservative” might mean not wanting changes to software as well as
> > not wanting changes to inequality in society but even so this
> > surprised me.
> 
> First, the general, rhetorical question, for everybody (not for
> DLL-Hell): What is the motivation for a person to join the mailing list
> of an anti-systemd, pro-choice distro, and start spouting pro-systemd
> stuff? What kind of a use of time is that? Why do several people keep
> doing this? What could they possibly gain?
> 
> These are rhetorical questions, of course: I hope this thread dies
> quickly, and that Mr. Hell is left to experience the silence of a
> breezeless rural Wisconsin summer afternoon.

Steve, DLL-Hell was quoting a blog post of Russell Coker and his reply
comments.  The URL was ill formed but included at the top of his message
to this list:

http://etbe.coker.com.au/2015/04/26/anti-systemd-people/

As I still read Planet Debian from to time, I saw Russell's post in
Liferea and read about half before I lost interest.  I didn't read far
enough to encounter his intellectual non sequitur equating a technical
objection to a piece of software to a social/legal/economic issue
championed by all manner of SJWs these days.  Apparently anyone can jump
to a conclusion and be comfortable with it while pointing fingers at the
"other" side for doing the same.  Everything in the email to this list
that shows etb: was written by Russell not DLL Hell as comparing the URL
above to the OP of this thread shows.

> But speaking of uses of time, to maximize mine, I did this:
> 
> =
> # Anti-systemd people hate women intellectual DLL Hell
> :0:
> * From.*trillodllh...@nativeweb.net
> * ^(To|Cc).*dng@lists.dyne.org
> $GARBAGE
> =

I don't know who DLL Hell is, although I have suspicions.  From that
post I really don't know his agenda as all but one or two sentences were
originally written by Russell Coker, a prominent Debian Developer.  Your
recipe, although instructive (after 16 years of using it I really need
to get a better handle on Procmail), is, IMO, unfair to DLL Hell at this
time.  Also, I doubt Russell will be posting here.

- Nate

-- 

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Ham radio, Linux, bikes, and more: http://www.n0nb.us
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] Debian Dev: anti-systemd people hate women; thus respectable people should not support anti-systemd stance.

[Ron]

On Sat, 2 May 2015 09:03:30 -0700
"DLL Hell"  wrote:

> anti-systemd people hate women; thus respectable people should not support 
> anti-systemd stance.

You forgot to say that anti-systemd people also love to hurt small animals, 
that they claim the holocaust of 12 million killed by the Nazi did not happen, 
and that they are all G.W.Bush-hating Democrats...
 
Cheers,
 
Ron.
-- 
   Puella Rigensis ridebat
Quam tigris in tergo vehebat;
  Exsterna profecta,
   Interna revecta,
 Risusque cum tigre manebat.

   -- http://www.olgiati-in-paraguay.org --
 

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[Dng] The new running installation of Devuan.

[Edward Bartolo]

The new running installation of Devuan is reminding me of the good old
days of Lenny. The memory use is impressive.

At boot, with Compositing Enabled:
edbarx@devuan-inst:~$ free -m
total   used   free sharedbuffers cached
Mem:  1940248   1692 38 11128
-/+ buffers/cache:107   1832
Swap: 3071  0   3071

I would like to take the opportunity to thanks ALL THOSE WHO WERE
INVOLVED to make this a reality.

Thanks.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] Debian Dev: anti-systemd people hate women; thus respectable people should not support anti-systemd stance.

[Jaromil]

dear Steve,

On Sun, 03 May 2015, Steve Litt wrote:
> =
> # Anti-systemd people hate women intellectual DLL Hell
> :0:
> * From.*trillodllh...@nativeweb.net
> * ^(To|Cc).*dng@lists.dyne.org
> $GARBAGE
> =


thanks.

Besides, Dyne.org policy for participation is not just against any
discrimination on gender, but queer-friendly. As long as Devuan is bound
to our organization, this will be a necessary condition. To this add
that Devuan's community has already a certain gender diversity among its
leaders which we expect only to grow in the future.

we will not tollerate any aggression of this sort to the communities we
host, all what has been posted here has to be regarded as an aggression
and will be acted upon, within reasonable time considering the weekend.

we are still not applying a moderation filter on all emails coming in.

ciao



signature.asc
Description: Digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] [dng] vdev status updates

[Laurent Bercot]

On 03/05/2015 10:15, marc...@welz.org.za wrote:

So you have just argued that to hide things from autocompletion,
one should make things 0700. We have also established that
for this scheme to work the shell needs to do a stat() *for* *each*
*candidate* executable. But the my /bin/bash does not do a
stat() - which is sensible, cause that would be slow. And I
couldn't parse if your zsh does or does not. So your proposed
solution does not work for most users. So then you say one shouldn't
rely on the autocompletion, because your advice (of merging /bin, /sbin
and then marking user-uninteresting executables 0700) will make that
mechanism unreliable, where it was quite reliable before. So your
solution breaks autocompletion.


 I am starting to wonder whether I really am that bad at expressing
myself. I'll try to clarify.

 * You said autocompletion with stat() would be slow. Fair enough.
(although profiling this would be interesting. How slow is "slow" ?
You mention smartphones or wearables, but how often do people run an
interactive shell on those ?)
 * I tested my zsh autocompletion, and observed that it does not
perform stat(), thus leaning your way. OK, 0700 do not hide binaries
from autocompletion, so in the current world, my suggestion does not
work.
 * I then argue that in the current world, autocompletion is not
reliable, because since it does not stat(), it cannot hide filenames
the user cannot execute, such as a 0644 file. What your autocompletion
is currently printing is an approximation of the programs you can run,
not an accurate list - in other words, merging /bin and /sbin would not
"break" autocompletion, because it is already "broken". You are just
not seeing it because the (good) convention of not putting anything
non-executable in /bin is widely followed - but the whole mechanism
is simply relying on a convention, and stricto sensu you should not
entirely trust it. The only way to make autocompletion reliable
would be to stat() every file it scans. Which may or may not be too
slow in practice.

 Note that I do not actually suggest merging /bin and /sbin. I think
that it would be too much effort for too little gain. I only said that
if a directory structure was designed today, without the weight of
historical practice and convention, then /sbin and /usr/sbin would
simply not be needed.



* You have say a setgid executable which probably isn't perfectly
   secure. You trust your admin crowd to run it, but maybe not
   a php script which has escaped apache.

* So you put it into /usr/sbin and do

   chmod 750 /usr/sbin
   chgrp admin /usr/sbin

* And now if an exploit for said setgid tool becomes available
   then the php script won't be able to run it.


 OK, thanks for clarifying. This isn't security through obscurity
indeed. However, you could achieve the exact same result by putting
this tool in /usr/bin - or anywhere else - with chown root:admin
and chmod 2750 - you don't need a separate directory to hold binaries
you only want a specific group to run.

 And chmodding /usr/sbin is less flexible than chmodding individual
executables, because all the executables you put into /usr/sbin will
only be accessible to group admin, whereas chmodding individual
executables allows you to select which group, or which user, will
be able to run them. So if I wanted to restrict a binary's
executability to a group, I would chmod that binary regardless of
its location; I would not set up a specific location to host
restricted binaries.



And in general, the R bit on files is there to hide data. If you
confuse that with obscurity then there would be no confidentiality
at all (and confidentiality, along with availability and integrity
are what make up security).


 I was referring to the lack of an r bit on the /usr/sbin *directory*,
which only hides file names, and is only useful if all your files
have unpredictable names (which is usually not the case at all for
executables).
 The real security in your design does not come from the lack of an
r bit, but from the lack of an x bit on that directory, which makes
the files non-accessible.



Note I didn't say exactly, I implied it was a cheap option to
give cp/tar/rsync to not build the full image and thereby improve
the security and reduce the size of the image. Selecting packages
and files individually is a lot more effort. Think about /sbin
as a "tag" on the executable saying "probably not interesting
to a normal user". This information isn't kept elsewhere,
and so automating this by other means isn't that easy.


 Sure, as an informational tag, /sbin makes sense. I agree that it
is convenient. But more effort must be put into trimming an image
if you want real security. Drop the security argument and I'm with
you.



Mount has an excuse to be a run by a user, given that fstab
supports the "user" mount option.


 I remember 10ish years ago, mount was actually /sbin/mount.
It migrated to /bin at some point, probably, as you say, when the
"user" mount optio

Re: [Dng] [dng] vdev status updates

[sa]

On 02.05.2015 15:40, Hendrik Boom wrote:


On Thu, Apr 30, 2015 at 11:42:24PM +0200, Didier Kryn wrote:

Le 30/04/2015 20:16, John Morris a écrit :

The FHS was carefully designed to accomodate things like NFS root,


Years ago I heard that /usr could be mounted read-only, and even shared
between different running copies of Linux by an NFS mount.

But I've never seen a distro that took this seriously enough that a
routine upgrade (with something like aptitude upgrade) would work.


I broadly use a simple configuration: readonly root over NFS and rw /var.
In this manner I've setup clusters for computational chemistry, student 
computer classes, nowadays thin clients and my own "desktops".


Back to the times of RedHat 5 it was not so simple: custom /dev stuff, 
generally needed some local storage for /var because of RAM shortage and 
so on. Since then, we have automagic /dev, aufs to forget completely 
about local hdd, less packages ignore fs layout in non-compatible manner.


Modern Debian works in readonly root like a charm. I update it within 
chroot on NFS server without any error. Changes over standard 
distribution are minor:

/var over aufs tmpfs(rw)+nfs(ro),
some symlinks (perhaps not at all today),
postinst script to update tftp storage after updating kernel/initrd stuff.

My friend used readonly /usr over NFS for years, which is more 
conventional setup than mine.


I kindly ask all developers, including of Devuan, who plan to change FS 
layout significantly, to think twice and not break things by assuming 
"typical usage".


--
sa
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] Debian Dev: anti-systemd people hate women; thus respectable people should not support anti-systemd stance.

[Laurent Bercot]

On 03/05/2015 06:44, Steve Litt wrote:

What is the motivation for a person to join the mailing list
of an anti-systemd, pro-choice distro, and start spouting pro-systemd
stuff? What kind of a use of time is that? Why do several people keep
doing this? What could they possibly gain?


 Be fair. There are also people who go and troll pro-systemd mailing-lists.
Not as many, but the ratio to the total amount of anti-systemd or
pro-systemd people is about the same in both camps.
 Trolling isn't a matter of opinion, but of immaturity, which is shared
equally and cannot be fought with rationality, so don't devote too much
brain time to wondering about its reasons. :)

--
 Laurent

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] [dng] vdev status updates

[marcxdv]

Hello again

> >>  0700 for root-only binaries would hide them from your shell's
> >>  autocompletion.
> >
> >Which would be lots of stat() system calls.
> 
>  If a shell doesn't make them, then it doesn't verify that a file is
> executable either. (I just checked with zsh: it doesn't indeed.)
> Sure, few people will install non-executable files in PATH search
> locations, but if autocompletion doesn't guarantee that a filename
> it prints will be executable, then it shouldn't be relied on, and
> it's not a good argument for /bin and /sbin separation.

So you have just argued that to hide things from autocompletion,
one should make things 0700. We have also established that
for this scheme to work the shell needs to do a stat() *for* *each*
*candidate* executable. But the my /bin/bash does not do a
stat() - which is sensible, cause that would be slow. And I
couldn't parse if your zsh does or does not. So your proposed
solution does not work for most users. So then you say one shouldn't 
rely on the autocompletion, because your advice (of merging /bin, /sbin
and then marking user-uninteresting executables 0700) will make that
mechanism unreliable, where it was quite reliable before. So your
solution breaks autocompletion.

> >Also on paranoid systems /sbin and /usr/sbin can itself be made 0700 or
> >0750, so that random users can't even work out what admin commands might
> >be there (hide suid exploits)
> 
>  I don't support security through obscurity, and you shouldn't either.

Security through obscurity is a term often misunderstood.
It states that knowledge of the implementation should
not allow one to break the access control/restriction. The
example I listed does none of the above. Here are the steps:

* You have say a setgid executable which probably isn't perfectly
  secure. You trust your admin crowd to run it, but maybe not
  a php script which has escaped apache.

* So you put it into /usr/sbin and do

  chmod 750 /usr/sbin
  chgrp admin /usr/sbin

* And now if an exploit for said setgid tool becomes available
  then the php script won't be able to run it. 

There is no knowledge of how this mechanism works which would
allow an attacker to bypass it.

And in general, the R bit on files is there to hide data. If you
confuse that with obscurity then there would be no confidentiality 
at all (and confidentiality, along with availability and integrity
are what make up security).

> >Or /sbin can be deleted/omitted entirely on containers/virtual images
> >where all admin has been done already.
> 
>  People who tailor images with exactly the binaries they need will do
> it regardless of the location of those binaries. 

Note I didn't say exactly, I implied it was a cheap option to
give cp/tar/rsync to not build the full image and thereby improve
the security and reduce the size of the image. Selecting packages
and files individually is a lot more effort. Think about /sbin
as a "tag" on the executable saying "probably not interesting
to a normal user". This information isn't kept elsewhere,
and so automating this by other means isn't that easy.

> If you don't need
> /sbin/route, you probably don't need /bin/mount either.

Mount has an excuse to be a run by a user, given that fstab
supports the "user" mount option. If that is a good idea or
not is unclear. But this discussion relates to the quality 
and assignment of the tag "not interesting to a normal user", you 
are arguing for abolishing that tag entirely. More meta-information 
under your own (not corporate/government ;-) control is typically 
a good thing, especially if it has been compiled already. 

Assume that we merge bin and sbin: Chances are in some years some 
clever spark will then abuse posix labels to tag executables 
as "for admin (historic sbin)" and everybody will think this is a 
big breakthrough.

> >So there are very good reasons for keeping the classic/standard layout.
> 
>  The reasons you gave so far are pretty minor.

I listed concerns relating to autocompletion and security which
are important to me

regards

marc
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng