Obviously the Unix idea is the right way, and the others are merely weak attempts of obfuscation.

The use of CR/LF predates Microsoft and was used by DEC (Digital Equipment Corp).

No, the order that worked was CR/LF, when using a Teletype ASR 33 printer for your output. Having got your print head to the right hand side, you gave it the CR and the print head mechanism set off at high speed for the left hand side of the printer. While it was travelling across you put in the line feed, which is much quicker to execute. By the time you gave it the first character of the next line the print head was in place and all was well. If you gave them in the order LF/CR then the first character of the next line was printed while the print head was still whizzing back and ended up being printed somewhere in the middle of the next line but smudged. I know, I have tried it! We used ASR33s for the output from our isotope counters, using the paper tape punch for our data transfer to our ICL 1903A.

https://en.wikipedia.org/wiki/Teletype_Model_33

Geoff

Learned quite a few things today. =^)
Thank you.

Now, off to see if I can find out how to recover my Devuan installtion from whatever apt-get clean and apt-get autoclean (apparently) did to it.

Cheers,

A.

Sort of like what was once known as (this dates me) CR or 'carriage return'.
Typing machines and telex terminals from long ago.

Almost exactly right, I'd say. Time has blessed us with three different ways of ending a line, all relating back to the use of these characters for printer control, and basically a matter of how it is represented on file. So, nowadays we have:

• the Microsoft line ending idea of using both CR (carriage return) and LF (line feed),

• the Apple idea of ending lines with only CR, and

• the Unix (and Linux) idea of ending lines with LF.

That line ending are characters within the files, to make up the traditional "text file" representation. Obviously the Unix idea is the right way, and the others are merely weak attempts of obfuscation.

For some reason, the fourth option of LF+CR never took hold, even though that's really the mechanical sequence that got implemented in type writers, and probably the "safest" motion for a ribbon printer, which otherwise might smudge the printing.

I see ...
Sort of like what was once known as (this dates me) CR or 'carriage return'.
Typing machines and telex terminals from long ago.

OK.

OK.

Indeed ...  =-)

groucho@devuan:~$ cat nonewline.txt
this is a test file made with jed without a final new_linegroucho@devuan:~$

groucho@devuan:~$ cat newline.txt
this is a test file made with jed with a final new_line 
groucho@devuan:~$ 

Yes.
But in a very ambiguous manner.
Why not just print "new line character missing"?

Exactly as you say:

1.
edit user_linssid

groucho ALL=(ALL) NOPASSWD:/usr/bin/linssid[cr]  <- this [cr] is the 'new line' character and % is edited out

2. Check with visudo -c

[root@devuan groucho]# visudo -c
/etc/sudoers: parsed OK
/etc/sudoers.d/README: parsed OK
/etc/sudoers.d/user_dmesg: parsed OK
/etc/sudoers.d/user_linssid: parsed OK
/etc/sudoers.d/user_shutdown: parsed OK
[root@devuan groucho]# 

Thank you very much for taking the time to explain this to me.
Much obliged.

Now I'm confident I'll be able to write files for /etc/sudoers.d/ as needed.

Cheers,

A.

ralph.ronnquist wrote:

    ... suspect the issue is rather the absence or presence of a newline at the end of the line.

I'm sorry, I don't understand what you mean.

Hmm. A "newline" is a character at the end of a line, and it belongs to the text of the line in the same way as space characters belong to the line, but it also is a separator between lines in the way space characters are separators between words. For visudo (and sudo, I guess) the (last) line must have a terminating newline.

Many editors though don't show much different for that last newline being there or not, and some editors (like vi) even force a final newline. Presumably the editor, jed(?), that you used, lets you end the last line without a newline character.

You can check that by making a one-line file, say xxxx.txt without entering a final newline, and then view it by cat xxxx.txt, which will show the text content of the file, and then, if the final newline is missing, the next command prompt becomes joined up on the same line.

So, you configuration file problem was that the first one-liner didn't have the terminating newline, and therefore visudo complained. As you added the % character to the beginning, you also happened to get a terminating newline, presumably because you then edited the file with a different editor (eg through visudo). The fix was due to that newline, and adding the % character "merely" changed the semantics of the line.

I see ...
Now user groucho in group groucho makes all the sense to me.
Thank you for taking the time to explain that.  =-)

OK.
Good to know.

And yes, I've very recently had to fix a cock-up and adduser groucho:groucho was what I used.
Almost locked myself out.

Yes, that I saw.
And since I am the only user in group groucho ...

OK. Now I have learned how to do that.

OK.

smartmontools, sudo service and chkroot-bootclean won't start from the CLI or from the user interface.
I have not tried other unstarted services or stopping any already started service to check how far this behavious goes.

Yes.
bootlogd is one of the first things I installed.
PCLinuxOS did not have it available (for some reason took it out of the repo) which, for a rolling release, made little sense to me.
It's one reason I left that distro, that boat rolls far too much for what I am used to and there are not enough life vests.   

I'll check that out.

Thank you very mych for your input.
Much appreciated.

Cheers,

A.

The % before sudo in /etc/sudoers is to identify sudo as a group. Groups are prefaced with %. (See man sudoers)

Then get your user out of the sudo group, and if you want more than shutdown commands available, add those other commands to sudoers.d/user_shutdown. (The name is just a name - what's inside the file determines what it does.)
deluser groucho sudo will remove the user groucho from the sudo group. If you want the user to enter a password for sudo, then remove NOPASSWD: from the line in user_shutdown.

I don't know why smartmontools won't start from command line, but I'm sure there's a good reason for it. You can still use smartctl on the command line - it doesn't need to be running as a service for that. If you want it to run tests automatically and/or notify you by email if there's a problem, then you need to turn it on in /etc/default/smartmontools and configure /etc/smartd.conf to do what you want.

Back around 2000, you were probably using ext2 filesystems, which are not journaled and take a lot longer to do a filesystem check. Be glad you're not seeing those messages. The filesystem is being checked at boot, but the message probably goes by too fast for you to see it. Install bootlogd, and you can find those messages in /var/log/boot.

You can change how frequently the filesystem checks are done by running tune2fs.

I like to see what goes on at boot time.
It is something I learned to do in my days as a MS minion.  :^,

So I have 'quiet' removed from the grub command line.

I'm sorry, I don't understand what you mean. 

Thanks for your input.

Cheers,

A.

Regarding your sudo configuration, I suspect the issue is rather the absence or presence of a newline at the end of the line.

Good ...
That's a relief.
Then it's an issue with my setup.

Not all, I just want the user to be able to use sudo for some (inocuous) commands
The rest, run with su.

I used PCLinuxOS for a time and they have this idea (which I adhere to) about the use of sudo:

But why won't it start by using either the CLI or the graphical interface?
Both are correct ways of doing it. (?)

Yes, it seems to be working OK.
There's still the issue of using % or not using % in the /etc/sudoers.d/ files but I have the feelong that it may be related to the existence of a group name matching a user name and the user belonging to that same group.

ie: user groucho belonging to group groucho.

It's all been very enlightening.

It's listed as a service to run in  Applications -> System -> Services = [service]. 

From: https://unix.stackexchange.com/question … it-scripts

I found it interesting to see what it did so I wanted to start the service.
The sudo service I understood and made sense to me to have it running.

What I was really looking for was something I recall seeing years ago (ca. 2000?) in my very early (and unsuccessful) attempts to install Debian on an old laptop.
After a certain amount of days, a script would run and inform you that X days had passed since the last file system check and was now running it. 
I have not seen it since in any distrbution I've tried.

Thanks a lot for your input.

Cheers,

A.

That is a good thing (IMO) and what I was wanting to accomplish by starting sudo service.

OK.

Yes.
My installation gets to root by means of su.

Now I do, thanks to your post.   =-)

Indeed ...
That's exactly what it is doing, as there is a group called 'groucho'.
I cannot recall creating it myself, but that does not mean much.  8^/.

BTW:
Group 'groucho has Group ID 1000 and my user 'Julis Henry Marx' belongs to it.

I'll have to look into that and see where group 'groucho' came from.
I think it was created at installation time. (?)

I'll see what happens if I take myself out of it.

But then, if I am the user groucho, why didn't using groucho (instead of %groucho) work?
Could it be that there's a sort of hierachy which which sudo works?
ie: first groups matching and then users?

I have a feeling that there being a group with a name that matches a user name is confusing sudo.
ie: user groucho belonging to group groucho.

I'll try to clean this up and see how it goes.

Thank you very much for your input.

Cheers,

A.

If you don't want the user to be able to use sudo for all commands, then remove that user from the sudo group. You'll still be able to shutdown, etc., becuase of sudoers.d/user_shutdown. And you don't need visudo to edit that file; just edit it as root.

To start smartmontools/smartd, edit /etc/default/smartmontools to uncomment #start_smartd=yes.

You don't have to start the sudo service. Use sudo if you want, or don't use it. It's obviously working correctly on your system.

I don't know what checkroot-bootclean.sh does. It doesn't show up in sysv-rc-conf as a service to start/stop, but there is a symlink for it to start in runlevel 1. I see no reason to mess with it.

You can change how long it remembers by setting timestamp_timeout in /etc/sudoers. Setting it to 0 should make sudo always ask for a password when you use it.

It's a good idea to have another way to get to root (eg su) when experimenting with sudo. So a typo in /etc/sudoers won't lock you out. And keep one terminal session running as root and use another to test sudo as your id.

I'm not sure why you had to add a % to the line in /etc/sudoers.d/[file_name] (mentioned in the other thread). In the line you showed changing groucho to %groucho should make it match members of the group called groucho instead of user groucho. But it's been several years since I've had to use sudo to do more than changing to root.

Chris

It's rather over my head but if it's to prevent sudo permissions from surviving a reboot it would not have to do much more. (?)

But I have at least three services that are not starting with the graphic interface or with the command line in a terminal.

Hmmm ...
That I don't like.

I can at times be hasty and distracted (maybe it's age?) and recognise the need to be called to attention: requiring me to enter an admin PW does that.
I don't mind being able to run sudo for a selected few commands but not all/any commands.

groucho@devuan:~$ sudo blkid
[sudo] password for groucho: 
/dev/sda1: UUID="1ACC-311B" TYPE="vfat" PARTUUID="000e0731-01"
--- snip ---
groucho@devuan:~$ 

It asks for a PW.
Probably because there isn't a dedicated file for that action in /etc/sudoers.d?
BTW: I have tried to create a working file there for tesing purposes but have failed, visudo -c does not like it..
See my other thread (where I split this one from).

# Allow members of group sudo to execute any command
%sudo	ALL=(ALL:ALL) ALL

It is commented with a percent sign (%) instead of a number/pound sign (#)?

I can also ...
My guess is that it is because of the /etc/sudoers.d/user_shutdown file.
If so, % is not being used to comment a line.
But what is it for? (what's the sysntaxis?)

OK ...
At least I have not screwed something up.  8^º

Can you start other unstarted services?

No idea ...

But (from what I can understand) the issue goes further: I want to start a service and it will not start by any one of the two known methods.
Does not look right.

I suspect a problem somewhere. (?)
I also see the same problem in the Miyo Linux installation I have on another drive/same hardware.

Thanks for your input.

Cheers,

A.

If your user is in the sudo group, you should be able to use sudo with your password for all commands. Try something safe like sudo blkid to see if that works. What I don't understand is why user_shutdown works when the includedir directive in /etc/sudoers is commented out. It's commented out in mine, too, but I can shutdown using sudo without password. I'm also getting the same results as you for 'service --status-all' - it doesn't change when I try to start sudo. Maybe that's because sudo runs and then exits after it changes the time stamp.

Edit: 'man sudoers' just answered my question.