Re: [DNG] Xorg stopped working after upgrade to Beowulf

[Marc Shapiro via Dng]

Actually, it says that it cannot connect to the Wicd daemon, or something
to that effect.

Sorry,
  Marc

On Tue, Sep 22, 2020, 9:52 PM Marc Shapiro  wrote:

> Yes, that solved the issue.  I installed elogind and libpam-elogind,
> rebooted and X now starts up for all three users.
>
> There is only one issue.  For only ONE of the three users, after X starts,
> my dughter's login gets a popup that says the Wicd client cannot be
> started, make sure the user is in the netdev group.  Well, she wasn't in
> the netdev group, so I logged her out, added her to the group, logged her
> back in and verified that she was in netdev, then ran startx.  I am still
> getting the same error.  Is there something else that is required for the
> Wicd client?
>
> Marc
>
>
> On 9/22/20 7:43 AM, Marc Shapiro wrote:
>
> I do use startx from a terminal login, so this sounds like it could be the
> problem.  I'll check it out when I get home, tonight and pass the results
> to the list.
>
> Thanks.
>
> Marc
>
>
>
> On 9/21/20 11:16 PM, wirelessduck--- via Dng wrote:
>
>
>
> On 22 Sep 2020, at 12:36, Marc Shapiro via Dng 
>  wrote:
>
> I have pretty much decided that there is no way to upgrade my Debian
> system to Buster and keep it usable without systemd.  Since I am set up for
> multiboot, including Devuan Ascii, I decided to upgrade that to Beowulf and
> see if that will work for me and the others using this box.
>
> After upgrading (following the instructions for upgrading an existing
> Devuan system), I rebooted the computer.
>
> First, I booted into my Debian Stretch partition to make sure that
> everything was still good, there.  Boot, login, start Xorg. All looks good.
>
> Logout and reboot into Beowulf.
>
> Boot and login went fine.  Starting Xorg, not so well.  Tried all three
> users with no luck.  This worked before the upgrade.  Tried as root.
> Success!  So root can start Xorg, but not an ordinary user.  Any ideas what
> might be wrong.  It looks like a permissions issue, but I don't know enough
> about how X actually starts up to know where to look.  Anything that you
> want me to post to help debug this?
>
> Any help appreciated.
>
>
> Marc
>
>
> If you are starting X from a terminal/tty, the Beowulf release notes
> mention the required configuration to start X as non-root.
>
> https://files.devuan.org/devuan_beowulf/Release_notes.txt
>
> —
> Tom
>
> ___
> Dng mailing 
> list...@lists.dyne.orghttps://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Xorg stopped working after upgrade to Beowulf

[Marc Shapiro via Dng]

Yes, that solved the issue.  I installed elogind and libpam-elogind, 
rebooted and X now starts up for all three users.


There is only one issue.  For only ONE of the three users, after X 
starts, my dughter's login gets a popup that says the Wicd client cannot 
be started, make sure the user is in the netdev group.  Well, she wasn't 
in the netdev group, so I logged her out, added her to the group, logged 
her back in and verified that she was in netdev, then ran startx.  I am 
still getting the same error.  Is there something else that is required 
for the Wicd client?


Marc


On 9/22/20 7:43 AM, Marc Shapiro wrote:


I do use startx from a terminal login, so this sounds like it could be 
the problem.  I'll check it out when I get home, tonight and pass the 
results to the list.


Thanks.

Marc



On 9/21/20 11:16 PM, wirelessduck--- via Dng wrote:



On 22 Sep 2020, at 12:36, Marc Shapiro via Dng  
wrote:


I have pretty much decided that there is no way to upgrade my 
Debian system to Buster and keep it usable without systemd.  Since I 
am set up for multiboot, including Devuan Ascii, I decided to 
upgrade that to Beowulf and see if that will work for me and the 
others using this box.


After upgrading (following the instructions for upgrading an 
existing Devuan system), I rebooted the computer.


First, I booted into my Debian Stretch partition to make sure that 
everything was still good, there.  Boot, login, start Xorg. All 
looks good.


Logout and reboot into Beowulf.

Boot and login went fine.  Starting Xorg, not so well.  Tried all 
three users with no luck.  This worked before the upgrade.  Tried as 
root.  Success!  So root can start Xorg, but not an ordinary user.  
Any ideas what might be wrong.  It looks like a permissions issue, 
but I don't know enough about how X actually starts up to know where 
to look.  Anything that you want me to post to help debug this?


Any help appreciated.


Marc


If you are starting X from a terminal/tty, the Beowulf release notes 
mention the required configuration to start X as non-root.


https://files.devuan.org/devuan_beowulf/Release_notes.txt 



—
Tom

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

[DNG] OT? Re: ..devuan to the rescue? Easiest possible newbie email server setup, ideas?

[terryc]

On Sat, 19 Sep 2020 23:55:46 +0200
Arnt Karlsen  wrote:

> Hi,
> 
> 
> ..devuan to the rescue?  Norwegian ISP "Get" is ditching their email
> service and pointing their clients to a paid service, which again is
> pointing them to Gmail's ad laden services, drawing due scorn. [1]

To be brief;
It isn't technically Devuan that is the solution, but Gnu/Linux.

The only thing that really made me grimace, is that you are willing
to do all this for generic  'windows' users(GWU). I see a world of hurt.

IME(in my experience) GWU tend to downoad and install programs with
unwanted add-ons which can mean you will spend a lot of time fixing the
problem and removing your domain/mail-server off blacklists.

You will have to write a lot of documentation with explicit How-To steps
for everything. You know, that stuff that has always been missing from
Unix time.

So I suggest you are going to have to process all their outgoing emails
to try an minimise this problem. No suggestions, MS boxen are not for
sending email here nd they are blocked on the fire wall.

YMMV, but IME GWU have trouble performing a simple copy and past of the
headers, which makes problem solving 'interesting'

Now to my 2c on your various points.

I've run sendmail since I first set up a domain mail service over a
dial up link.

I use zen.spamhaus.org as the only checker and a healthy sendmail access
file. 

The norm seems to be to just accept everything and process it, but
until recently, all my internet services cam with a data charge. So for
our domain, the easiest & cheapest method is just to block known
spammers and not pay data charges.

FWIW, I do not accept email by IPv6.

As to a mailer, I currently use claws as there is a "one button/right
click select) report this spam to spamcop.net. It also does all the
fetching/collecting from multiple mailboxes AND sending via my choice of
mailbox.

It also has a comprehensive filtering/sorting system. my only complaint
is it can be difficult to later edit the various rules, as when you
sign up for a list and use only "TO:"(very easy to do) and later want to
change it to "TO_or_CC", which has to be manually edited.


What is missing from our domain is an automated capacity for users to
add an aliases for all these lists they want to sign up to.


Summary, the technical problems are easy. It is the users that will
get you.






TL;DR  response
(well actuas
> 
> 
> ..since we can do better, I'm thinking "Devuan Email Server Flavor" 
> sort of distro to put on an old pc or a Raspberry Pi, with all email
> on local storage like I've done since the mid 1990ies.  Which is 
> part of my problem: While Claws Mail is neat and easy, Fetchmail 
> and Procmail are _far_ from newbie friendly.
> 
> ..expect the Get clientele to be total newbies, who may be capable of 
> entering their own email account data into a web browser interface 
> from their Wintendo, so our new email server flavor needs to be kept 
> as stupid simple as possible to setup and use.  
> 
> 
> ..limit it to a pop3 and imap client and an imap server with local
> storage?  The big thing is control over your own email, on your own
> hardware, in your own home.
> 
> ..me, I use Fetchmail as an imap and pop3 client to fetch my email, 
> and Procmail to sprinkle it down my ~/Mail tree, and Claws Mail to 
> read it, and to write and to send my outgoing email, directly out 
> thru my isp's smtp servers.  That's all I really need.  
> 
> ..the Get clientele will have similar needs, but will need their 
> "home email server" as stupid simple as possible to setup and use. 
> Easiest possible newbie email server setup, use and support, ideas?  
> 
> ..the competition:
> https://www.popsci.com/set-up-private-email-server/
> https://www.geekwire.com/2015/why-you-shouldnt-try-to-host-your-own-email/
> https://helpdeskgeek.com/how-to/how-to-set-up-your-own-email-server/
> https://www.linux.com/topic/networking/how-build-email-server-ubuntu-linux/
> https://www.pcworld.com/article/3184925/how-to-have-a-linux-home-server-on-the-cheap.html
> https://arstechnica.com/information-technology/2014/02/how-to-run-your-own-e-mail-server-with-your-own-domain-part-1/
> https://jeffreifman.com/how-to-install-your-own-private-e-mail-server-in-the-amazon-cloud-aws/
> https://www.iredmail.org/
> https://docs.iredmail.org/why.build.your.own.mail.server.html
> 
> 
> ..'1: The Norw. original news story:
> https://www.tek.no/nyheter/nyhet/i/Qml8dx/get-overfoerte-kundene-sine-til-epostselskap-som-naa-vil-ha-betalt-fo?utm_source=vgfront_content=row-30
> 
> ..the above in googlish:
> TESTS
> NEWS
> SERVICES
> GUIDES
> 
> Menu
> NEWS
> Get transferred its customers to email companies that will now have
> paid. - Reprehensible, says customer 
> Customers who previously used Getmail were transferred to Wemail this
> summer. Now Wemail requires customers to subscribe to keep their email
> address.
> 
> Screenshot
> Stein Jarle Olsen
> and
> Niklas Plikk
> 18 SEPT 2020 13:39
> 
> 90+

[DNG] ..devuan to the rescue? Easiest possible newbie email server setup, ideas?

[Arnt Karlsen]

Hi,


..devuan to the rescue?  Norwegian ISP "Get" is ditching their email
service and pointing their clients to a paid service, which again is
pointing them to Gmail's ad laden services, drawing due scorn. [1]


..since we can do better, I'm thinking "Devuan Email Server Flavor" 
sort of distro to put on an old pc or a Raspberry Pi, with all email
on local storage like I've done since the mid 1990ies.  Which is 
part of my problem: While Claws Mail is neat and easy, Fetchmail 
and Procmail are _far_ from newbie friendly.

..expect the Get clientele to be total newbies, who may be capable of 
entering their own email account data into a web browser interface 
from their Wintendo, so our new email server flavor needs to be kept 
as stupid simple as possible to setup and use.  


..limit it to a pop3 and imap client and an imap server with local
storage?  The big thing is control over your own email, on your own
hardware, in your own home.

..me, I use Fetchmail as an imap and pop3 client to fetch my email, 
and Procmail to sprinkle it down my ~/Mail tree, and Claws Mail to 
read it, and to write and to send my outgoing email, directly out 
thru my isp's smtp servers.  That's all I really need.  

..the Get clientele will have similar needs, but will need their 
"home email server" as stupid simple as possible to setup and use. 
Easiest possible newbie email server setup, use and support, ideas?  

..the competition:
https://www.popsci.com/set-up-private-email-server/
https://www.geekwire.com/2015/why-you-shouldnt-try-to-host-your-own-email/
https://helpdeskgeek.com/how-to/how-to-set-up-your-own-email-server/
https://www.linux.com/topic/networking/how-build-email-server-ubuntu-linux/
https://www.pcworld.com/article/3184925/how-to-have-a-linux-home-server-on-the-cheap.html
https://arstechnica.com/information-technology/2014/02/how-to-run-your-own-e-mail-server-with-your-own-domain-part-1/
https://jeffreifman.com/how-to-install-your-own-private-e-mail-server-in-the-amazon-cloud-aws/
https://www.iredmail.org/
https://docs.iredmail.org/why.build.your.own.mail.server.html


..'1: The Norw. original news story:
https://www.tek.no/nyheter/nyhet/i/Qml8dx/get-overfoerte-kundene-sine-til-epostselskap-som-naa-vil-ha-betalt-fo?utm_source=vgfront_content=row-30

..the above in googlish:
TESTS
NEWS
SERVICES
GUIDES

Menu
NEWS
Get transferred its customers to email companies that will now have
paid. - Reprehensible, says customer 
Customers who previously used Getmail were transferred to Wemail this
summer. Now Wemail requires customers to subscribe to keep their email
address.

Screenshot
Stein Jarle Olsen
and
Niklas Plikk
18 SEPT 2020 13:39

90+
This summer, Get (now Telia) notified customers who have used the email
service Getmail that their email service would be discontinued and that
they would be transferred to the external service Wemail. The problem?
A couple of weeks later, Wemail was informed that in a relatively short
time they would demand a subscription fee of 19 kroner a month for
customers to keep their emails.

Wemail, which is run by the company Recurrent AS, explains on its own
website that they are a Norwegian mail service without advertisements,
and that they do not use data about customers for commercial purposes.
Therefore, they are dependent on revenue from customers. Wemail
apparently has no other customers than the previous Get customers.

Several readers have contacted and reacted strongly to the fact that
they now have to pay for a service that was previously included.

"Directly reprehensible," says one. "Incredibly poor customer service",
says another, who is also upset that Wemail gave customers "very short"
deadlines and in practice threatened that the email archive would be
deleted and the email address useless if you did not create a
subscription.

He also points out that many people use these email addresses to log in
in many places.

- Informed in May
Information manager Daniel Barhom in Telia says affected customers were
  not informed until May.

- Those who did not want to transfer the e-mail address to Wemail were
  free to close their account then - and of course they still do.
  According to our figures, there were approximately 25,000 customers
  where we had registered that there was use of the e-mail account.
  Pure TV customers at Get have not had Getmail.


Daniel Barhom in Telia says they knew that Wemail would charge, but
that the company takes self-criticism on the communication to customers.

Telia
The alternative was to close down the entire service, says Barhom - and
Telia did not want that.

- One of the many reasons for the transfer was that Wemail has the
  resources to maintain and maintain an e-mail service in a way Get
  could no longer, and it was then decided to discontinue the e-mail
  service. Get then entered into an agreement with Wemail that they
  took over e-mail accounts for customers who did not close their
  account.

- Did you know that Wemail would 

Re: [DNG] Xorg stopped working after upgrade to Beowulf

[viverna]

il devuanizzato Marc Shapiro via Dng  il 22-09-20 16:43:42 
ha scritto:
I do use startx from a terminal login, so this sounds like it could be 
the problem.  I'll check it out when I get home, tonight and pass the 
results to the list.

I installed xserver-xorg-legacy then:
chmod +s /usr/lib/xorg/Xorg

You can change /etc/X11/Xwrapper.config file:
allowed_users=console

man Xwrapper.config for info it should fit your needs

You can start X with:
startx
or you custom script
or ax at https://notabug.org/viverna/ax
or xinit with custom command line, for example:
xinit /home/user/.xinitrc -- /etc/X11/xinit/xserverrc :0 vt2 -keeptty

without use any graphical login manager for X11.

--
_
< Viverna >
-
  \^/^
   \  / \  // \
\   |\___/|  /   \//  .\
 \  /0  0  \__  ///  | \ \   **
   / /  \/_///   |  \  \  \   |
   @_^_@`/   \/_   //|   \   \ \/\ \
   //_^_/ \/_ // |\\ \  \
( //) |\///  | \ \   |  |
  ( / /)  | //   |  \ _\ |  /
( // /)   |  ; -.|_ _\.-~   /   /
  (( / / ))   |_  *-.|.-~-.   .~~
 (( // / ))\  / ~-. _ .-~  /
 (( /// ))  `.   }{   /
  (( / ))  .~-.\\-` .~
   ///...<\ _ -~
  ///-._ _ _ _ _ _ _{^ - - - - ~
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Danger: Debian POSIX hostility

[Harald Arnesen via Dng]

Rick Moen [22.09.2020 20:11]:

>> I worry about a different kind of portability. If I ever have to switch
>> to BSD (and this remains a possibility, unfortunately), /bin/* shebangs
>> will not work except for /bin/sh, and /bin/sh is always ash. That is
>> because on BSD everything not in the core system goes into /usr/local.
> You know, if going for maximum portability, you can rely, within the
> shebang, on /usr/bin/env.  Like:
> 
> #!/usr/bin/env bash
> 
> Although there's no absolute guarantee that env(1) will reside in
> /usr/bin on all Unix machines ever made, it does live there on BSDs.
> And I'm willing to bet that it's going to exist and be in /usr/bin on
> Unixes made written the last quarter-century.

And if you have to use a Unix system without env in /usr/bin, you can
always symlink or copy it there. Provided you have root access, of course.
-- 
Hilsen Harald
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Danger: Debian POSIX hostility

[Rick Moen]

Quoting Ian Zimmerman (i...@very.loosely.org):

> I worry about a different kind of portability. If I ever have to switch
> to BSD (and this remains a possibility, unfortunately), /bin/* shebangs
> will not work except for /bin/sh, and /bin/sh is always ash. That is
> because on BSD everything not in the core system goes into /usr/local.

You know, if going for maximum portability, you can rely, within the
shebang, on /usr/bin/env.  Like:

#!/usr/bin/env bash

Although there's no absolute guarantee that env(1) will reside in
/usr/bin on all Unix machines ever made, it does live there on BSDs.
And I'm willing to bet that it's going to exist and be in /usr/bin on
Unixes made written the last quarter-century.

https://stackoverflow.com/questions/10376206/what-is-the-preferred-bash-shebang#10383546
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Danger: Debian POSIX hostility

[Rick Moen]

Quoting Peter Duffy (pe...@pwduffy.org.uk):

> With respect, I'd tend to disagree with that to some extent. The /bin/sh
> symlink is built in, and is there from the point that the system is
> installed.

That was a _second_ if lesser blunder (in that bash was, even at the
inception of Linux, a poor approximation of the Bourne shell), but
doesn't excuse the one of failing to put /bin/bash in the shebang if one
intends to write a bash-specific script.  Which is what was actually
under discussion.

> So it's a feature made available to users, and it's arguably
> not a blunder to use it.

It's not a blunder to use a /bin/sh -> /bin/bash symlink.  It's a
blunder to fail to specify bash in the shebang if you're writing a bash
script.

> I'd agree that best practice is specifying bash explicitly in the
> shebang, if it's required (something that I personally have always done
> since I first bitten by the bash/dash problem).

For values of 'best practices' approximating 'This will prevent your
script accidentally breaking if you use bash-specific features and 
your script ends up being run at a time or place where /bin/sh is
something other than bash.'

> I'm trying to remember what happens on systems that default to ksh and
> csh - I assume that on those, the shebang always needs to specify the
> shell to be used.

ksh and pdksh are fairly close approximations of the Bourne shell.  csh
and tcsh are very much not.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Danger: Debian POSIX hostility

[Ian Zimmerman]

On 2020-09-22 17:25, Antony Stone wrote:

> If you're writing portable scripts you don't want to rely on symlinks
> pointing to the same targets on everything.
> 
> If your scripts aren't (intended to be) portable, then it really
> doesn't matter - do what you like in the privacy of your own machine.

I worry about a different kind of portability. If I ever have to switch
to BSD (and this remains a possibility, unfortunately), /bin/* shebangs
will not work except for /bin/sh, and /bin/sh is always ash. That is
because on BSD everything not in the core system goes into /usr/local.

Therefore, I made symlinks /usr/local/bin/{bash,dash} and the shebangs
in my newly written scripts reference those. I am not religious about
converting every old script to the new usage, but I do update them when
they require maintenance.

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

Re: [DNG] Danger: Debian POSIX hostility

[Ian Zimmerman]

On 2020-09-22 11:21, Steve Litt wrote:

> I would never use Bash in a shellscript.

I think that's a bit too strong. Some scripting situations are a perfect
fit for the shell with the exception of one or two little features
missing in the POSIX shell but present in bash. My top examples would be
the pipefail option and process substitution ie. <(foo) and >(foo).

It's worthwhile to have a build of bash with all the interactive
features disabled (job control, history, completion etc etc). I think at
one point (maybe before dash?) there was even a debian package providing
such a build. Does memory deceive me?

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

Re: [DNG] Xorg stopped working after upgrade to Beowulf

[Ian Zimmerman]

On 2020-09-22 11:10, Steve Litt wrote:

> Second, a more security-respecting solution is there might be a group,
>  which your users can belong, that allows them to run X. Perhaps
> group video ??? I just looked at /usr/bin/Xorg on my Void box and it's
> not suid anything. I performed some ls commands that show no suid
> owner, group or everyone that pertain to X:

Unfortunately, I don't think this will help.

The problem is not just file system accesses, but specialized ioctl
system calls, which are reserved for root. They were supposed to be
cleaned up with the switch to kernel side modesetting (KMS), but some
remain. And to make this even more opaque and frustrating, this depends
on the driver used, hence on the hardware.

This is the only reason why I use xdm. I feel that between xdm and a
setuid Xorg, the former is the lesser evil when configured right,
ie. listening only on a unix socket.

This (longish) sub-thread from my gentoo days may be relevant:

https://archives.gentoo.org/gentoo-user/message/15777398d780425417e5f5414dc903c1

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

Re: [DNG] Danger: Debian POSIX hostility

[Antony Stone]

On Tuesday 22 September 2020 at 17:21:25, Steve Litt wrote:

> I would never use Bash in a shellscript. Therefore, do you think my
> shebang should just go straight to #!/bin/dash instead of #!/bin/sh ?
> That would certainly take the ambiguity out of it.

Yes.

If you're writing portable scripts you don't want to rely on symlinks pointing 
to the same targets on everything.

If your scripts aren't (intended to be) portable, then it really doesn't 
matter - do what you like in the privacy of your own machine.


Antony.

-- 
"Hi, I've found a fault with the English language and I need an entomologist."
"I think you mean an etymologist."
"No.  It's a bug, not a feature."

   Please reply to the list;
 please *don't* CC me.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Danger: Debian POSIX hostility

[Steve Litt]

On Tue, 22 Sep 2020 10:53:15 +0100
Peter Duffy  wrote:

> On Mon, 2020-09-21 at 18:07 -0700, Rick Moen wrote:
> > Quoting marc (marc...@welz.org.za):
> >   
> > > Hmm - that might require some background: I'd venture that most of
> > > these scripts were written when sh was just a symlink to bash, and
> > > dash didn't exist, nevermind as a debian package.  
> > 
> > But that was always a blunder.  The shebang should have been set to
> > bash explicitly, if bash-specific features are used:  In the cases
> > of which you spoke, the coder made a lazy and unsupportable
> > assumption.  
> 
> With respect, I'd tend to disagree with that to some extent. The
> /bin/sh symlink is built in, and is there from the point that the
> system is installed. So it's a feature made available to users, and
> it's arguably not a blunder to use it. Whether it's a good feature or
> not is definitely a moot point. The convention in linux (think since
> it originated) was that /bin/sh pointed to bash - until Debian
> decided to do it differently. 

I would never use Bash in a shellscript. Therefore, do you think my
shebang should just go straight to #!/bin/dash instead of #!/bin/sh ?
That would certainly take the ambiguity out of it.

Or maybe I should shebang all my shellscripts #!/bin/littshell . That
way, if I ever found a better alternative than dash, or if I operated
on a system without dash, I could just change a symlink. The downside
would be that none of my shellscripts could work on computers without
the /bin/littshell symlink.

Or should I just make sure /bin/sh always points to dash?

Thanks,

SteveT

Steve Litt 
Autumn 2020 featured book: Thriving in Tough Times
http://www.troubleshooters.com/thrive
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Danger: Debian POSIX hostility

[Steve Litt]

On Tue, 22 Sep 2020 10:33:12 +0100
Peter Duffy  wrote:


> My main feeling was one of frustration: bash's new features were
> introduced as an improvement, not as a deliberate violation of
> standards. Ubuntu/Debian's defaulting to dash just seemed like an act
> of puritanism. 

I wouldn't call it puritanism. Bash is a wonderful interactive shell: I
would never want to be without it. But it's huge, a little slower to
load, and it has a lot of nooks and crannies for bugs to hide. Dash is
meant to be a programming language, loads faster, and is less likely to
have bugs. My preference is to use the best interactive shell for
interacting, and the best programming shell for programs.
 
SteveT

Steve Litt 
Autumn 2020 featured book: Thriving in Tough Times
http://www.troubleshooters.com/thrive
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Xorg stopped working after upgrade to Beowulf

[fraser kendall]

On Tue, 22 Sep 2020 07:43:42 -0700
Marc Shapiro via Dng  wrote:

> I do use startx from a terminal login

Me too, and usually without problems.  However, I have always had to
add 

needs_root_rights=yes

to /etc/X11/Xwrapper.config

And lately I cannot startx on three beowulf/xfce4 desktops, I have to
startxfce4 (and the panel's not that stable either).

Best wishes

fraser

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

Re: [DNG] Xorg stopped working after upgrade to Beowulf

[Steve Litt]

On Mon, 21 Sep 2020 19:36:33 -0700
Marc Shapiro via Dng  wrote:


> Boot and login went fine.  Starting Xorg, not so well.  Tried all
> three users with no luck.  This worked before the upgrade.  Tried as
> root. Success!  So root can start Xorg, but not an ordinary user.
> Any ideas what might be wrong.

Hi Marc,

I don't use Devuan much, and haven't used Debian since March 2015, but
I have some ideas from my general wanderings through Linux.

First of all, there's an ancient fix, passed from father to son
throughout the ages, of making X or Xorg or one of the shellscripts
that calls it suid root.

Second, a more security-respecting solution is there might be a group,
to which your users can belong, that allows them to run X. Perhaps
group video ??? I just looked at /usr/bin/Xorg on my Void box and it's
not suid anything. I performed some ls commands that show no suid
owner, group or everyone that pertain to X:


[slitt@mydesk trumptoll]$ ls -l /usr/bin | grep -v ^[-ld]
total 3005208
[slitt@mydesk trumptoll]$ ls -l /usr/bin | grep -v ^...[-x]
total 3005208
-rwsr-xr-x 1 root root 71960 Feb 14  2020 chage
-rwsr-xr-x 1 root root 39056 Jul 29 10:50 chfn
-rwsr-xr-x 1 root root 30864 Jul 29 10:50 chsh
-rwsr-xr-x 1 root root 30768 Jan 20  2019 contain
-rwsr-xr-x 1 root root 22592 Jan  1  2019 dcrontab
---s--x--x 1 root root 43176 Feb  3  2020 doas
-rwsr-xr-x 1 root root 26984 Feb 14  2020 expiry
-rwsr-xr-x 1 root root 34952 Jan  5  2019 fusermount
-rwsr-xr-x 1 root root 34968 Jun 17 16:15 fusermount3
-rwsr-xr-x 1 root root 67704 Feb 14  2020 gpasswd
-rwsr-xr-x 1 root root 55360 Jul  4 19:09 ksu
-rwsr-xr-x 1 root root 59536 Jul 29 10:50 mount
-rwsr-sr-x 1 root root 43864 Dec 25  2019 mount.cifs
-rws--x--x 1 root root129824 Jul 20 14:05 mount.nfs
-rwsr-xr-x 1 root root 37208 Feb 14  2020 newgidmap
-rwsr-xr-x 1 root root 14480 Jul 29 10:50 newgrp
-rwsr-xr-x 1 root root 37208 Feb 14  2020 newuidmap
-rwsr-xr-x 1 root root 59760 Feb 14  2020 passwd
-rwsr-xr-x 1 root root 30784 Aug  8  2019 pkexec
-rwsr-xr-x 1 root root 48832 Jun 27  2017 pmount
-rwsr-xr-x 1 root root 22576 Jan 20  2019 pseudo
-rwsr-xr-x 1 root root 35200 Jun 27  2017 pumount
-rwsr-xr-x 1 root root470104 Feb  7  2020 screen-4.8.0
-rwsr-xr-x 1 root root 40488 Feb 14  2020 sg
-rwsr-xr-x 1 root root 14456 Nov 21  2016 slock
-rwsr-xr-x 1 root root 18528 Jul  4 07:25
spice-client-glib-usb-acl-helper -rwsr-xr-x 1 root root 71824
Jul 29 10:50 su ---s--x--x 1 root root161904 Jul 23 17:13 sudo
-rwsr-xr-x 1 root root116888 Nov 29  2018 udevil
-rwsr-xr-x 1 root root 34960 Jul 29 10:50 umount
-rwsr-xr-x 1 root root 38984 Mar 20  2019 unix_chkpwd
-rwsr-x--- 1 root xbuilder 22616 Jul  2 10:57 xbps-uchroot
[slitt@mydesk trumptoll]$ ls -l /usr/bin | grep -v ^..[-x]
total 3005208
-rwxr-sr-x 1 root cgred14496 Oct 16  2018 cgexec
-rwxr-sr-x 1 root _mlocate 39064 Sep  7  2018 mlocate
-rwxr-sr-x 1 root root497616 Apr 27 05:38 mlterm
-rwsr-sr-x 1 root root 43864 Dec 25  2019 mount.cifs
-r-xr-sr-x 1 root _smtpq  228176 Jul  4 19:09 smtpctl
-rwxr-sr-x 1 root tty  34960 Jul 29 10:50 wall
-rwxr-sr-x 1 root tty  22672 Jul 29 10:50 write
[slitt@mydesk trumptoll]$ 


I don't have time right now to remove myself from group video, kill X,
re-login, run X, and see if I can't run X, but I think group video is
something to check.

SteveT

Steve Litt 
Autumn 2020 featured book: Thriving in Tough Times
http://www.troubleshooters.com/thrive
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Xorg stopped working after upgrade to Beowulf

[Marc Shapiro via Dng]

I do use startx from a terminal login, so this sounds like it could be 
the problem.  I'll check it out when I get home, tonight and pass the 
results to the list.


Thanks.

Marc



On 9/21/20 11:16 PM, wirelessduck--- via Dng wrote:



On 22 Sep 2020, at 12:36, Marc Shapiro via Dng  
wrote:


I have pretty much decided that there is no way to upgrade my Debian 
system to Buster and keep it usable without systemd.  Since I am set 
up for multiboot, including Devuan Ascii, I decided to upgrade that 
to Beowulf and see if that will work for me and the others using this 
box.


After upgrading (following the instructions for upgrading an existing 
Devuan system), I rebooted the computer.


First, I booted into my Debian Stretch partition to make sure that 
everything was still good, there.  Boot, login, start Xorg. All looks 
good.


Logout and reboot into Beowulf.

Boot and login went fine.  Starting Xorg, not so well. Tried all 
three users with no luck.  This worked before the upgrade.  Tried as 
root.  Success!  So root can start Xorg, but not an ordinary user.  
Any ideas what might be wrong. It looks like a permissions issue, but 
I don't know enough about how X actually starts up to know where to 
look. Anything that you want me to post to help debug this?


Any help appreciated.


Marc


If you are starting X from a terminal/tty, the Beowulf release notes 
mention the required configuration to start X as non-root.


https://files.devuan.org/devuan_beowulf/Release_notes.txt 



—
Tom

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

Re: [DNG] Danger: Debian POSIX hostility

[Peter Duffy]

On Mon, 2020-09-21 at 18:07 -0700, Rick Moen wrote:
> Quoting marc (marc...@welz.org.za):
> 
> > Hmm - that might require some background: I'd venture that most of
> > these scripts were written when sh was just a symlink to bash, and
> > dash didn't exist, nevermind as a debian package.
> 
> But that was always a blunder.  The shebang should have been set to bash
> explicitly, if bash-specific features are used:  In the cases of which
> you spoke, the coder made a lazy and unsupportable assumption.

With respect, I'd tend to disagree with that to some extent. The /bin/sh
symlink is built in, and is there from the point that the system is
installed. So it's a feature made available to users, and it's arguably
not a blunder to use it. Whether it's a good feature or not is
definitely a moot point. The convention in linux (think since it
originated) was that /bin/sh pointed to bash - until Debian decided to
do it differently. 

I'd agree that best practice is specifying bash explicitly in the
shebang, if it's required (something that I personally have always done
since I first bitten by the bash/dash problem). I'm trying to remember
what happens on systems that default to ksh and csh - I assume that on
those, the shebang always needs to specify the shell to be used.

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

Re: [DNG] Danger: Debian POSIX hostility

[Peter Duffy]

On Tue, 2020-09-22 at 02:20 +0200, marc wrote:
> > One thing about this which strikes me as a bit ironic is debian's use of
> > the dash shell, made to be POSIX-compliant, and so causing endless
> > problems for scripts using bash's additional non-POSIX functionality,
> > but not specifying bash explicitly in the shebang line.
> 
> Hmm - that might require some background: I'd venture that
> most of these scripts were written when sh was just a symlink
> to bash, and dash didn't exist, nevermind as a debian
> package.
> 
> The word decree is too strong, but at some point debian
> system scripts were supposed to be written to be /bin/dash
> compatible, but instead of changing all existing system scripts
> to start with /bin/bash, and only replacing them
> with /bin/sh once full checked/rewritten, they were kept
> at /bin/sh as people hoped for the best - a quick win.
> 
> I, for one, never bought into the reasoning for migrating
> system scripts away from bash to sh. The argument that
> bash is too large struck me as odd - there were critical
> dependencies on perl and python with a much larger dependency
> graph, and much bigger startup costs... 
> 
> More importantly I think it is good that one uses the same language 
> that one types into the terminal every day when extending the 
> distribution - that makes a sysadmin equal to the distribution maintainer, 
> instead of specialising that into a different caste... 
> 
> regards
> 
> marc

I was bitten by this when the company which I worked for (about 8 years
ago) decided to move their development environment from Red Hat to
Ubuntu - it turned out that the two were so incompatible that we ended
up having to provide each user with separate Red Hat and Ubuntu PCs. But
we still had to make the development system work under both
environments. 

Most of the development process was driven by a big suite of
shellscripts. The first we knew that there was a problem was when the
builds under Ubuntu failed with no indication of why. It turned out that
they used bash features - the one which really hit us was the use of
"==" in test expressions (illegal in dash). For some reason (can't
remember why), we couldn't change the shebang, so had to work through
all the scripts and find workarounds for the bash features. It wasn't a
nice task. 

My main feeling was one of frustration: bash's new features were
introduced as an improvement, not as a deliberate violation of
standards. Ubuntu/Debian's defaulting to dash just seemed like an act of
puritanism. 

The situation became even worse when it was decided to revert to using
bash as the default interactive shell, but keep /bin/sh pointing to
dash. So an admin script would be written, and work fine (in bash) - and
then be set up as a cron task, whereupon it would fail (because it was
now running under dash). OK, the fix was easy - just specify the exact
shell in the shebang - but remembering to do that took some effort for a
while.


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

Re: [DNG] Xorg stopped working after upgrade to Beowulf

[wirelessduck--- via Dng]

> On 22 Sep 2020, at 12:36, Marc Shapiro via Dng  wrote:
> 
> I have pretty much decided that there is no way to upgrade my Debian system 
> to Buster and keep it usable without systemd.  Since I am set up for 
> multiboot, including Devuan Ascii, I decided to upgrade that to Beowulf and 
> see if that will work for me and the others using this box.
> 
> After upgrading (following the instructions for upgrading an existing Devuan 
> system), I rebooted the computer.
> 
> First, I booted into my Debian Stretch partition to make sure that everything 
> was still good, there.  Boot, login, start Xorg. All looks good.
> 
> Logout and reboot into Beowulf.
> 
> Boot and login went fine.  Starting Xorg, not so well.  Tried all three users 
> with no luck.  This worked before the upgrade.  Tried as root.  Success!  So 
> root can start Xorg, but not an ordinary user.  Any ideas what might be 
> wrong.  It looks like a permissions issue, but I don't know enough about how 
> X actually starts up to know where to look.  Anything that you want me to 
> post to help debug this?
> 
> Any help appreciated.
> 
> 
> Marc

If you are starting X from a terminal/tty, the Beowulf release notes mention 
the required configuration to start X as non-root.

https://files.devuan.org/devuan_beowulf/Release_notes.txt

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