You are not logged in.
- Topics: Active | Unanswered
#1801 Re: Desktop and Multimedia » [SOLVED] Nvidia error at boot » 2018-09-19 21:55:16
Hello:
... found this forum and registered to add this ...
Welcome and thank you. :-)
... 3, different, amd64 machines all running "ascii" ...
... non-free nvidia drivers.
... three have different nvidia cards.
OK.
Nice sampling.
... generate the error described above:
[time] udevd[xx]: Error running install command for nvidia
Seems something common then?
... ascii on all three ...
... switched 2 of them from Mint because ...
I went Ubunbtu -> Mint --> CrunchBang --> PCLinuxOS, allways two at the same time and got here for the same reasons with the exception of # ! which Newborough (developer) gave up on.
So I plan to stay here for the long run.
... alll 3 machines work great, video works fine.
Same here.
But there's a problem at boot time, right before the desktop comes up: on two of my three monitors I get artifacts made up of a sort checkerboard type design in black, grey and white square/rectangular portions of different sizes which last a few seconds.
Apparently no big deal but it is rather annoying.
I think it is (?) a problem with the package or the driver version used in the package because I did not get them (error in dmesg or artifacts) when I ran PCLinuxOS on this same rig. ie: exactly the same hardware but using Mate instead of Xfce.
Do you get any artifacts like the ones I am attempting to describe?
Maybe it's an issue due to the three monitor setup?
... how to remove the erroneous error reported in dmesg, but it looks like we are not their yet
Ideally it would be good to know the origin of the error and act upon that.
Thank you very much for your input.
Cheers,
A.
#1802 Re: Installation » Firefox 60.2.0esr - Rollback » 2018-09-14 22:45:36
Hello:
... humor me for a minute, what about Quantum did you dislike?
Sure ... =-)
Was it only the UI?
[humour mode]
More than anything, the UI.
The new absolutely unneeded dancing dots and progress line that show as a page is loading.
I mean, WTF?
And then there's this new way the drop-down folders in the menu bar open to the right and only to the right.
There have been many complaints about this last one on the web and the proposed solution actually was to edit all your bookmarks so they will be shorter and thus not go off the screen (on to the next one in my case).
Really?
I tell you, whoever is in charge of the Firefox UI design does not seem to be the brightest lightbulb in the room.
Then there's the addons I lost, so I'll wait to see what happens and eventually (if things don't get straightened out) see about using another browser.
I have not lost hope but I won't be holding my breath.
How long did it take the Mozilla crew to realise that those damn 'rounded borders' were crap?
[/humour mode]
Cheers,
A.
#1803 Re: Installation » Firefox 60.2.0esr - Rollback » 2018-09-14 22:24:23
Hello:
... instead of using third-party stuff, why don't you just get the packages from the Debian repo?
Well ...
1.
... run them to see which version was the last before these guys screwed up ...
2.
Once I found out that the one I wanted was Firefox-55.0.glibc2.3.4-x86_64, I went looking for it but the repo jumps from 52.9 to 60.4.
That's about it.
Cheers,
A.
#1804 Re: Installation » Firefox 60.2.0esr - Rollback » 2018-09-14 10:34:33
Hello:
Thanks for the fast reply.
... just download the package and install it.
OK.
... a copy of the package in /var/cache/apt/archives/.
No, it's not one of the packages there.
Must have cleaned up recently.
I've downloaded a few of the available AppImage files from bintray.com and run them to see which version was the last before these guys screwed up the interface (more than they already had).
You just download it to a suitable place in you /home folder, make it executable and start it.
It picks up all your settings.
Running one of these *.AppImage files may be even better than installing the application., I have to check how that can be done.
In case anyone else is interested, the version without the improvements to the interface is Firefox-55.0.glibc2.3.4-x86_64.AppImage.
From then on ... : ^/
Thanks for your input.
Cheers,
A.
#1805 Installation » Firefox 60.2.0esr - Rollback » 2018-09-13 22:13:11
- Altoid
- Replies: 8
Hello:
On Fri Sep 7 22:18:12 2018 I upgraded firefox-esr (52.9.0esr-1~deb9u1) to 60.2.0esr-1~deb9u2, something I deeply regret.
I'd like to rollback to the previous version firefox-esr (52.9.0esr-1~deb9u1) or maybe something in-between and pin it.
60.2 is a POS interface wise.
Just what are these guys at Mozilla thinking?
How can I do this without screwing up my installation?
Is it OK to just fetch the package from the Debian repos and install it?
Thanks in advance,
A.
#1806 Re: Installation » Intel Management Engine module in Devuan ASCII » 2018-09-07 16:00:36
Hello:
... Coreboot needs to become the norm for more systems.
No ...
Coreboot needs to become the norm for all systems.
My Sun Microsystems Ultra24 came out with a flawed BIOS, to the extent that it reports itself as a portable system.
The last (very hard to obtain) BIOS upgrade put out by Sun in the midst of it's gobble up by Oracle was held hostage and did not address this issue which is negligible if you compare it to a severe shutdown issue it has.
groucho@devuan:~$ inxi -Fzx
System: Host: devuan Kernel: 4.9.0-8-amd64 x86_64 (64 bit gcc: 6.3.0) Desktop: Xfce 4.12.3 (Gtk 2.24.30)
Distro: Devuan GNU/Linux ascii
Machine: Device: portable System: Sun Microsystems product: Ultra 24 v: 0.00.01
Mobo: Sun Microsystems model: Ultra 24 v: 50 BIOS: American Megatrends v: 1.56 date: 01/21/2011The people who valiantly undertake making Coreboot barely have time and resources for today's boards and then for only a fraction of what is available.
Coreboot should be an industry norm.
Blanking the Intel ME at boot (like they are) seems like the bigger hammer to neutralize Intel problems.
Of course.
... wanted to Coreboot but he put that on pause when he realized he could brick the boards.
Unless you have a sure-fire way of recovering from a failed BIOS flash, you have to assume that you will brick it.
There's many of us in that boat.
Cheers,
A.
#1807 Re: Installation » Login problem - no mouse or keyboard » 2018-09-04 17:18:47
Hello:
... pour over the release notes in detail tonight or tomorrow morn ...
I've checked the release notes.
In particular, the part that refers to "Session management and policykit backends"
I was able to verify that my installation complies with all the requirements ie: the "recommended default
combination of login manager (either slim or lightdm) and session management system."
As to "Starting X from a console (TTY)", although I was being able to do it in the manner described ... (in spite of having consolekit and not elogind installed)
If from the grub screen I hit 'e' and add a 1 to the end of the command line and then, instead of logging in as root, I continue with the boot process ie: with ctrl-d I can do startx and get a perfectly working desktop.
... it was with the Shutdown and Restart options being greyed out, probably the effect of not having elogind installed.(?)
So I just in case, to comply with the Release Notes requisites, I installed SLiM (which I had previously removed) and reinstalled consolekit, in case it had become mucked up somehow.
The consequence was that the working desktop described above recovered the ability to Shutdown and Restart from the panel. =-)
Afterwards, looking closely at the screen output for a few reboot cycles made me aware of an issue regarding one of the services I had not been able to start.
The thread can be read here
It turns out that the service checkroot-bootclean.sh was failing to execute properly and, not seeing anything else that could have been giving me trouble, I went for it.
Being a script that apparently runs at boot and then exits (?) does not seem like a service to me, it looks more like what it is: a start up script.
No wonder querying it with service --status-all | grep -i checkroot- did not list it as running and me making a fuss over that.
Shouldn't there be a Script Starting Service with a list of scripts to check as needed?
But I digress ...
The fact was that it was being executed at boot and it was failing.
The graphical interface for Services was of no help whatsoever so I looked for the script and edited the .sh in the name. ie: *.sh -> *.old and rebooted.
Sure enough: it was the culprit.
Now I had recovered a fully working desktop.
Which meant that apparently, apt-get clean and apt-get autoclean were not at fault.
At least not this time.
But I was still getting boot time warnings about the bootclean script failing albeit with no apparent ill effects.
I tried to use chkconfig to sort that out, but could not find it: it seems to have been dropped from ASCII (I clearly recall using it in Jesse).
Then I found out about update-rc.d, which was installed.
I thought using it would clean things up for me and that would be it.
So I did update-rc.d -f /etc/init.d/checkroot-bootclean.sh remove but doing so left me without any screen output. =^/
At that point this whole thing was getting old and I was needing my dose of espresso so I decided to take the easy way out.
But I'm not too happy about that.
I went to my Timeshift folder and recovered all the rcX.d folders in /etc from last saturday's snapshot and after renaming the existing ones as rcX.old, copied the backed up versions over to /etc and that was that.
Things seem to be back to normal, whatever that is in this installation.
But I'd like to ask a couple of questions, if I may:
1. did I use update-rc.d correctly?
2. was it the proper approach to the problem at hand? ie: to clear out a script that I wanted to stop being run.
3. why can't the script be stopped with the graphical interface ie: Applications -> System -> Services = [service]
Thanks in advance.
Cheers,
A.
#1808 Re: Installation » Services start issue » 2018-09-03 23:53:46
Hello:
Almost exactly right ...
... with three different ways of ending a line ..
... line ending are characters within the files ...
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.
#1809 Re: Installation » Services start issue » 2018-09-03 23:01:01
Hello:
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.
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.
For visudo (and sudo, I guess) the (last) line must have a terminating newline.
OK.
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.
OK.
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.
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:~$ ... configuration file problem was that the first one-liner didn't have the terminating newline, and therefore visudo complained.
Yes.
But in a very ambiguous manner.
Why not just print "new line character missing"?
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.
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.
#1810 Re: Installation » Login problem - no mouse or keyboard » 2018-09-03 21:40:10
Hello:
I suspect that autoclean might not take eudev and our customized backend options into its equation.
I see ...
And how was I to know that ...
Make sure you have the backend compatible with your DE installed.
I have a stock-out-of-the-box Devuan ASCII that began as Jessie.
Xfce and the rest came with it, nothing fancy save for the non-free Nvidia legacy 340 drivers.
And ALWAYS check what is going to be nuked BEFORE you hit enter.
Sure ...
But apt did not give me/print ou any data or warnings related to what was being nuked that I could check or heed.
I can be reckless but (I think ...) I'm a few years past being dumb. ;^D!
In any case, if I trust apt-get update, apt-get install, apt-get upgrade and apt-get dist-upgrade to do things properly and not screw up anything, it stands to reason that I should be able to trust apt-get clean, apt-get autoclean and apt-get autoremove to also do things properly.
I'll call it the TTAG (Transitive Trust Apt-Get) theory, which unfortunately has not stood up to peer scrutiny. LOL!!!
Read the release notes.
I'll pour over the release notes in detail tonight or tomorrow morn, but in the meantime I really need to recover from this unfortunate blunder.
Any suggestions as to how I can go about it?
Any additional info you need to be able to appraise the situation?
Thanks in advance,
A.
#1811 Installation » Login problem - no mouse or keyboard » 2018-09-03 21:02:46
- Altoid
- Replies: 3
Hello:
After running apt-get clean && apt-get autoclean and rebooting I was left with a totally unresponsive mouse and keyboard.
The only way out is a hard reboot.
The exact same situation repeats itself if I boot into recovery mode and try to do startx as root: I get a desktop with a totally unresponsive mouse and keyboard and needing a hard reboot to get out.
But ...
If from the grub screen I hit 'e' and add a 1 to the end of the command line and then, instead of logging in as root, I continue with the boot process ie: with ctrl-d I can do startx and get a perfectly working desktop.
This same thing (yes, I never learn) happened to me with another distribution but only now realise that is is/may be related to running apt-get clean && apt-get autoclean.
Thinking it was a initscript problem, I reinstalled the package but no cigar.
Same with xfce. I even uninstalled SLiM with the same result.
Is it possible that running apt-get clean && apt-get autoclean has cleaned in excess?
Is there a log for apt?
Running apt-get check says everything is OK, so apparently nothing is broken. (?)
There is one noticeable difference in this desktop: Shutdown and Restart options are greyed out.
Only Log Out is available as the only user in this installation.
So I have to do sudo shutdown from a terminal but it asks me for the admin PW.
Any ideas as to what I may have mucked up now? :^,
Thanks in advance.
A.
#1812 Re: Installation » Services start issue » 2018-09-03 16:06:20
Hello:
... you create a user, there is a corresponding group of the same name created, and that is the primary group for the user.
I see ...
Now user groucho in group groucho makes all the sense to me.
Thank you for taking the time to explain that. =-)
... configured in /etc/adduser.conf. (I think if you add your user with 'useradd' instead of 'adduser' you won't get that behavior and will have to define group, shell, home and whatever else yourself.) Sudo will not be confused by this.
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.
The % before sudo in /etc/sudoers is to identify sudo as a group.
Groups are prefaced with %. (See man sudoers)
Yes, that I saw.
And since I am the only user in group groucho ...
I just want the user to be able to use sudo for some (inocuous) commands
The rest, run with su.... get your user out of the sudo group ...
... 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.)
OK. Now I have learned how to do that.
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.
OK.
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.
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.
... 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.
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.
You can change how frequently the filesystem checks are done by running tune2fs.
I'll check that out.
Thank you very mych for your input.
Much appreciated.
Cheers,
A.
#1813 Re: Installation » Services start issue » 2018-09-03 13:17:53
Hello:
... the fsck output, telling you that the file system hasn't been checked in X days ...
... configure by changing the boot command line.
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.
... 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.
Thanks for your input.
Cheers,
A.
#1814 Re: Installation » Services start issue » 2018-09-03 12:10:45
Hello:
... can start and stop services.
... seems to be working fine here.
Good ...
That's a relief.
Then it's an issue with my setup.
... want the user to be able to use sudo for all commands ...
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:
"When implementing sudo, care should be taken to limit a users entry in /etc/sudoers to the absolute minimum of specific commands needed to perform the task at hand."
To start smartmontools/smartd, edit /etc/default/smartmontools to uncomment #start_smartd=yes.
But why won't it start by using either the CLI or the graphical interface?
Both are correct ways of doing it. (?)
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.
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.
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.
It's listed as a service to run in Applications -> System -> Services = [service].
From: https://unix.stackexchange.com/question … it-scripts
"The *-bootclean.sh scripts clean up files that must or should not survive a reboot: files in /var/run, /var/lock, /tmp, etc.
Checkroot-bootclean.sh runs just after the root filesystem is mounted (which can remove spurious files created under directories that will soon become mount points, such as /run and potentially /tmp)"
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.
#1815 Re: Installation » Services start issue » 2018-09-03 11:32:58
Hello:
... sudo service clears that so you always get asked for a password the first time you use sudo after a reboot.
That is a good thing (IMO) and what I was wanting to accomplish by starting sudo service.
... 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.
OK.
It's a good idea to have another way to get to root (eg su) ...
Yes.
My installation gets to root by means of su.
... had to add a % to the line in /etc/sudoers.d/[file_name] ...
Now I do, thanks to your post. =-)
... changing groucho to %groucho should make it match members of the group called groucho instead of user groucho.
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.
#1816 Re: Installation » [Solved] Permisison issue with winecfg » 2018-09-03 02:48:52
Hello:
... the % always puzzled me ...
... happy to hear you worked things out.
Thank you.
Here's yet more % puzzle for you.
The correct thing to do was to add a percent sign at the beginning of the line, like this:
%groucho ALL= NOPASSWD: /usr/bin/linssid
Well ...
Not always so.
Quite happy with being able to get away with generating a file for the /etc/sudoers.d/ directory, I set about doing it again.
This time for a command I use very often: dmesg.
Since using it with sudo was inocuous, I followed my own instructions and wrote up a file called user_dmesg with this line:
%groucho ALL= NOPASSWD: /usr/bin/linssid
As you can clearly see, it has the necessary % sign at the beginning.
But visudo -c rejects it with the same argument it rejected the line which did not have the % sign at the beginning.
On a whim, I removed the % sign and ....
It worked!
[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]# And just why would this be so?
The only answer that I can come up with is that the use of the % sign is directly related to the path of the command to run with sudo.
ie:
/bin/dmesg <-- this command does not need the % sign.
/usr/bin/linssid <-- this command does need the % sign.
/sbin/shutdown <-- this command does not need the % sign.
So maybe it's that the files in the /etc/sudoers.d/ need a line with a % sign at the beginning if the command is in the /usr path.
I have not found any documentation on this (the syntax for these files) but given the need to be able to adequately restrict the use of sudo, it would be nice to be able to do it properly.
Any further info would be appreciated.
Thanks in advance,
A.
#1817 Re: Installation » [Solved] Permisison issue with winecfg » 2018-09-02 16:26:18
Hello:
The I ran a check with visudo -c to see if it was OK ...
[root@devuan groucho]# visudo -c >>> /etc/sudoers.d/user_linssid: syntax error near line 1 <<< parse error in /etc/sudoers.d/user_linssid near line 1 [root@devuan groucho]#... but it was not.
I do not understand the error near line 1: there's only one line and it is practically the same as the one in user_shutdown.
Am I doing something wrong or is editing with jed the problem?
Indeed ...
But just how was I to know what I was doing wrong?
The existing file in /etc/sudoers.d was copied exactly and properly edited with visudo.
And still ...
OK.
The solution ended up being this: ---> %
The line that makes up any file you want to add to the /etc/sudoers.d/ directory (apparently) has to be preceded by a percent (%) sign.
Otherwise it will not work.
I have not been able to find a place where the syntax for these files is explained.
This example I posted above was wrong:
To do this I opened the file with jed and saved it as user_linssid and edited it with jed so that ...
groucho ALL= NOPASSWD: /usr/sbin/pm-suspend, /usr/sbin/pm-hibernate, /sbin/halt, /sbin/reboot
... becamegroucho ALL= NOPASSWD: /usr/bin/linssid
The correct thing to do was to add a percent sign at the beginning of the line, like this:
%groucho ALL= NOPASSWD: /usr/bin/linssid
I found out about this by reading this post: https://askubuntu.com/questions/930768/ … sodoers-fi.
And although it makes no mention of the percentage sign thing, I saw that a line in a /etc/sudoers.d file used it.
So I tried it and it worked. =^º
[rant mode]
How could I have possibly known this if the existing /etc/sudoers.d/users_shutdown file reads like this:
[root@devuan groucho]# cat /etc/sudoers.d/user_shutdown
groucho ALL= NOPASSWD: /usr/sbin/pm-suspend, /usr/sbin/pm-hibernate, /sbin/halt, /sbin/reboot <-- just [u]where[/u] is the % sign?
[root@devuan groucho]# And if using visudo to look at it shows me the exact same string of characters?
I mean, where is the f***ing percent sign?
[/rant mode]
Moral of the story:
Want to make a /etc/sudoers.d/file to avoid mucking up (very easy to do) the sudoers file?
1. copy an existing one.
2. edit it with visudo.
ie:
visudo -f /etc/sudoers.d/[file_name]3. make sure that you add a % sign at the start of the line.
4. save it with the intended name eg: user_whatever so you'll know what it is for.
5. make sure the file has 440 permissions.
ie:
[root@devuan groucho]# chmod 440 /etc/sudoers.d/[file_name]
5. check it all with visudo -c
[root@devuan groucho]# visudo -c
/etc/sudoers: parsed OK
/etc/sudoers.d/README: parsed OK
/etc/sudoers.d/user_whatever: parsed OK
/etc/sudoers.d/user_shutdown: parsed OK
[root@devuan groucho]# Of course, remember that you have to be a member of the sudoers group otherwise this is all moot.
Caveat: I'm no expert and WRT Linux I'm sort of playing by ear, so if any of the Devuan forum members with experience could take a minute to check that all this is not hogwash or has any errors, I'd be very obliged.
Cheers,
A.
#1818 Re: Installation » Services start issue » 2018-09-01 22:43:57
Hello:
... looks like all that script does is change the time stamp on /var/lib/sudo.
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. (?)
... only command it takes is 'start'.
... (stop|restart|whatever) do nothing.
But I have at least three services that are not starting with the graphic interface or with the command line in a terminal.
... your user is in the sudo group, you should be able to use sudo with your password for all commands.
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.
... safe like sudo blkid to see if that works.
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).
What I don't understand is why user_shutdown works when the includedir directive in /etc/sudoers is commented out.
# Allow members of group sudo to execute any command
%sudo ALL=(ALL:ALL) ALLIt is commented with a percent sign (%) instead of a number/pound sign (#)?
It's commented out in mine, too, but I can shutdown using sudo without password.
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?)
... also getting the same results as you for 'service --status-all' - it doesn't change when I try to start sudo.
OK ...
At least I have not screwed something up. 8^º
Can you start other unstarted services?
Maybe that's because sudo runs and then exits after it changes the time stamp.
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 ticked them in Applications -> System -> Services = [service], a pop-up for systemtoolsbackends.set asks me to authenticate and I type my root PW in.
Then I click Close but for some reason they won't start.
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.
#1819 Installation » Services start issue » 2018-09-01 20:26:30
- Altoid
- Replies: 15
Hello:
I run an up-to-date Devian ASCII:
groucho@devuan:~$ uname -ap
Linux devuan 4.9.0-8-amd64 #1 SMP Debian 4.9.110-3+deb9u4 (2018-08-21) x86_64 GNU/Linux
groucho@devuan:~$
groucho@devuan:~$ suThere seems to be a problem with the starting of (some?) services.
I ticked them in Applications -> System -> Services = [service], a pop-up for systemtoolsbackends.set asks me to authenticate and I type my root PW in.
Then I click Close but for some reason they won't start.
The services are checkroot-bootclean.sh, smartmontools and sudo.
So I try to start them from a TTY (just two for brevity's sake)
1. Check they are not already running:
[root@devuan groucho]# service --status-all | grep sudo
[ ? ] alsa-utils
[ ? ] cryptdisks
[ ? ] cryptdisks-early
[ ? ] hwclock.sh
[ ? ] kmod
[ ? ] networking
[ - ] sudo
[root@devuan groucho]# service --status-all | grep smartmontools
[ ? ] alsa-utils
[ ? ] cryptdisks
[ ? ] cryptdisks-early
[ ? ] hwclock.sh
[ ? ] kmod
[ ? ] networking
[ - ] smartmontools
[root@devuan groucho]#2. Start them as root:
[root@devuan groucho]# service sudo start
[root@devuan groucho]# service smartmontools start3. Check if they have started:
[root@devuan groucho]# service --status-all | grep sudo
[ ? ] alsa-utils
[ ? ] cryptdisks
[ ? ] cryptdisks-early
[ ? ] hwclock.sh
[ ? ] kmod
[ ? ] networking
[ - ] sudo
[root@devuan groucho]# service --status-all | grep smartmontools
[ ? ] alsa-utils
[ ? ] cryptdisks
[ ? ] cryptdisks-early
[ ? ] hwclock.sh
[ ? ] kmod
[ ? ] networking
[ - ] smartmontools
[root@devuan groucho]# This is a thread split from another one with a similar (?) issue here: https://dev1galaxy.org/viewtopic.php?id=2337.
My installation uses su to get root and my user is included in the sudo group.
[root@devuan groucho]# cat /etc/sudoers
#
# This file MUST be edited with the 'visudo' command as root.
#
# Please consider adding local content in /etc/sudoers.d/ instead of
# directly modifying this file.
#
# See the man page for details on how to write a sudoers file.
#
Defaults env_reset
Defaults mail_badpass
Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
# Host alias specification
# User alias specification
# Cmnd alias specification
# User privilege specification
root ALL=(ALL:ALL) ALL
# Allow members of group sudo to execute any command
%sudo ALL=(ALL:ALL) ALL
# See sudoers(5) for more information on "#include" directives:
#includedir /etc/sudoers.d
[root@devuan groucho]# groucho@devuan:~$ groups
groucho adm dialout cdrom floppy tape sudo audio dip video plugdev netdev lpadmin scanner
groucho@devuan:~$ I can sudo shutdown, sudo reboot, etc. as permitted by /etc/sudoers.d/user_shutdown.
[root@devuan groucho]# cat /etc/sudoers.d/user_shutdown
groucho ALL= NOPASSWD: /usr/sbin/pm-suspend, /usr/sbin/pm-hibernate, /sbin/halt, /sbin/reboot
[root@devuan groucho]# Any idea as to what is happening with services.?
Thanks in advance,
A.
#1820 Re: Installation » [Solved] Permisison issue with winecfg » 2018-08-31 10:36:03
Hello:
... man page for sudoers.
... options include timestamp_timeout which sets how often it asks ...
Thanks ... =-)
The timestamp feature could be overkill, even for me. LOL
... EDITOR=jed visudo which should let you edit /etc/sudoers with jed and have it checked.
Great ...
The checking feature is really nice to have.
But I've discovered sudo service which I did not know about.
Seems to be more suited to my use than a timestamp.
# make sure privileges don't persist across reboots
---------------------------------------------------------------------------------
EDIT: I have started another thread for this specific issue here https://dev1galaxy.org/viewtopic.php?id=2342
I have it ticked in Applications -> System -> Services = sudo.
But for some reason it won't start:
[root@devuan groucho]# service --status-all | grep sudo
[ ? ] alsa-utils
[ ? ] cryptdisks
[ ? ] cryptdisks-early
[ ? ] hwclock.sh
[ ? ] kmod
[ ? ] networking
[ - ] sudo
[root@devuan groucho][root@devuan groucho]# service sudo start
[root@devuan groucho]# service --status-all | grep sudo
[ ? ] alsa-utils
[ ? ] cryptdisks
[ ? ] cryptdisks-early
[ ? ] hwclock.sh
[ ? ] kmod
[ ? ] networking
[ - ] sudo
[root@devuan groucho]# Edit:
I have discovered that it's not only Applications -> System -> Services = sudo that does not start even though it I marked it.
The other services I marked (smartmontools and checkroot-bootclean.sh) also fail to start.
The services utility asks me for the admin PW and nothing else. ie: does not reject my credentials.
---------------------------------------------------------------------------------
To practise and learn about sudo, I had a look at the file in /etc/sudoers.d/user_shutdown to make one exactly like it for LinSSID and not have to muck around with editing the sudoers file which is dangerous, as I found out for myself. (many thanks to Timeshift!).
To do this I opened the file with jed and saved it as user_linssid and edited it with jed so that ...
groucho ALL= NOPASSWD: /usr/sbin/pm-suspend, /usr/sbin/pm-hibernate, /sbin/halt, /sbin/reboot
... became
groucho ALL= NOPASSWD: /usr/bin/linssid
I saved the file and gave it 0440 permissions which I have read is a must for files in sudoers.d:
[root@devuan sudoers.d]# chown 0440 user_linssid
[root@devuan sudoers.d]# The I ran a check with visudo -c to see if it was OK ...
[root@devuan groucho]# visudo -c
>>> /etc/sudoers.d/user_linssid: syntax error near line 1 <<<
parse error in /etc/sudoers.d/user_linssid near line 1
[root@devuan groucho]# ... but it was not.
I do not understand the error near line 1: there's only one line and it is practically the same as the one in user_shutdown.
Am I doing something wrong or is editing with jed the problem?
Thanks in advance.
A.
#1821 Re: Installation » [Solved] Permisison issue with winecfg » 2018-08-30 20:00:34
Hello:
I was just about to post.
I managed to get things working with PMail.
The problem was that I had added myself the the sudo group but had not logged in again. :^ '
Wasn't going to get anywhere that way.
My *.desktop file for PMail is this ...
[Desktop Entry]
Type=Application
Name=PMail
Exec=wine start /unix /home/groucho/.wine/drive_c/PMAIL/Programs/winpm-32.exe
MimeType=application/x-ms-dos-executable;application/x-msi;application/x-ms-shortcut;
Icon=/home/groucho/pmail_32x32x32.png
NoDisplay=true
StartupNotify=true
GenericName=PMail32
Comment=
Terminal=false
Path=... and it works as intended.
Look in /etc/sudoers ...
[root@devuan groucho]# cat /etc/sudoers
#
# This file MUST be edited with the 'visudo' command as root.
#
# Please consider adding local content in /etc/sudoers.d/ instead of
# directly modifying this file.
#
# See the man page for details on how to write a sudoers file.
#
Defaults env_reset
Defaults mail_badpass
Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
# Host alias specification
# User alias specification
# Cmnd alias specification
# User privilege specification
root ALL=(ALL:ALL) ALL
# Allow members of group sudo to execute any command
%sudo ALL=(ALL:ALL) ALL
# See sudoers(5) for more information on "#include" directives:
#includedir /etc/sudoers.d
[root@devuan groucho]# Seems it's like you say.
... run visudo as root to add it (visudo edits a copy of /etc/sudoers with vi, then syntax checks your changes and copies it back if they are OK).
I have tried in the past to get around vi but I've found it very complicated to use.
I'm afraid I'm 20+ years late to that party, I learned the ropes with the early DOS 5.0 editors.
After trying three or four Linux CLI editors, I have finally settled on jed, it works for what I need to do.
Then try sudo -l to list what sudo will let you do. And sudo -i to get to a root shell.
groucho@devuan:~$ sudo -l
Matching Defaults entries for groucho on devuan:
env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User groucho may run the following commands on devuan:
(ALL : ALL) ALL
(root) NOPASSWD: /usr/sbin/pm-suspend, /usr/sbin/pm-hibernate, /sbin/halt, /sbin/reboot
groucho@devuan:~$ groucho@devuan:~$ sudo -i
[sudo] password for groucho:
[root@devuan ~]# It works ... =-)
Just in case:
groucho@devuan:~$ groups
groucho adm dialout cdrom floppy tape sudo audio dip video plugdev netdev lpadmin scanner
groucho@devuan:~$ id
uid=1000(groucho) gid=1000(groucho) groups=1000(groucho),4(adm),20(dialout),24(cdrom),25(floppy),26(tape),27(sudo),29(audio),30(dip),44(video),46(plugdev),102(netdev),109(lpadmin),111(scanner)
groucho@devuan:~$ One thing:
# Allow members of group sudo to execute any command
%sudo ALL=(ALL:ALL) ALLI don't want to be able to do anything with sudo, I would like to strictly limit what I can do as a member of the sudo group.
This ALL=(ALL:ALL) ALL seems (to me) rather excessive.
How can this be effectively limited without hampering the use of the OS?
Thank you very much for your input.
Cheers,
A.
#1822 Installation » [Solved] Permisison issue with winecfg » 2018-08-30 13:31:25
- Altoid
- Replies: 9
Hello:
I'm trying to set up Wine in my Devuan ASCII installation but I seem to have run into a problem related to permissions.
When I installed Devuan ASCII, I selected to use su and not sudo.
I see it as a sort of insurance from myself and the possibility of getting distracted and inadvertently wreaking havoc.
ie: this way I will always be reminded that whaever I am doing requires elevated privileges and will get them by entering the root PW.
But while I undertstand that this is not practical for some things, I have managed to get around the problem it brings up.
eg: to run LinSSID from a .desktop file, the command will be gksu linssid instead of the default gksudo linssid.
I don't mind having to enter a PW for an app I don't use a lot.
Now, when I run winecfg I am not able to set up the drives:
groucho@devuan:~$ winecfg
err:winecfg:open_mountmgr failed to open mount manager err 2
err:winecfg:open_mountmgr failed to open mount manager err 2
groucho@devuan:~$ If I run it with sudo, I get this:
groucho@devuan:~$ sudo winecfg
[sudo] password for groucho:
Sorry, user groucho is not allowed to execute '/usr/bin/winecfg' as root on devuan.
groucho@devuan:~$ My user is in the sudo group.
And if I run it as root, it creates a configuration directory in /root ...
[root@devuan groucho]# winecfg
wine: created the configuration directory '/root/.wine'
---
other stuff err: follows.
[root@devuan groucho]#... which will most probably (?) have the effect of needing to be root to run programs under Wine.
Is there a way to set up sudo on a per-application basis ...
ie: so that sudo will work with a select list of apps, like Wine and LinSSID.
... or am I going about this the wrong way?
Thanks in advance,
A.
#1823 Re: Installation » Timeshift 18.8 and Devuan ASCII » 2018-08-27 19:24:33
Hello:
... found it too complicated.
... tried about 5 restores and one of them failed
Yes, I know that it will render any legacy grub system unbootable.
I have had good comments after introducing it into the PCLinux forum.
... recommend partclone ...
... simple and has never let me down ...
... creates a compact image of your partition ...
I think I looked at it but the Timeshift convinced me because of it being automatic and scheduling, etc.
Seems to be much like Norton Ghost-DOS, which I used a lot when I was prisoner of the MS camp. =-)
It worked great most of the time.
... none of this answers your question, but I thought I'd share ...
On the contrary, thank you very much for taking the time to write and share your opinion/experience.
That's what this is all about, no?
Cheers,
A.
#1824 Re: Desktop and Multimedia » [SOLVED] Nvidia error at boot » 2018-08-27 12:37:46
Hello:
There's no one here that can shed some light on this?
Thanks in advance.
A.
#1825 Installation » Timeshift 18.8 and Devuan ASCII » 2018-08-26 23:13:07
- Altoid
- Replies: 3
Hello:
I'm needing a system restore app and, having used it on other distros, was wondering if anyone here has installed Timeshift.
TimeShift
https://launchpad.net/timeshiftTimeShift for Linux is an application that provides functionality similar to the System Restore feature in Windows and the Time Machine tool in Mac OS. TimeShift protects your system by taking incremental snapshots of the file system at regular intervals. These snapshots can be restored at a later date to undo all changes to the system.
Snapshots are taken using rsync and hard-links. Common files are shared between snapshots which saves disk space. Each snapshot is a full system backup that can be browsed with a file manager.
TimeShift is similar to applications like rsnapshot, BackInTime and TimeVault but with different goals. It is designed to protect only system files and settings. User files such as documents, pictures and music are excluded. This ensures that your files remains unchanged when you restore your system to an earlier date. If you need a tool to backup your documents and files please take a look at the excellent BackInTime application which is more configurable and provides options for saving user files.
These are the links:
https://github.com/teejee2008/timeshift
https://github.com/teejee2008/timeshift … stallation
https://github.com/teejee2008/timeshift/releases
A *.RUN installer which I have never used before is available for download.
Will it work properly (thinking dependencies and such) with Devuan ASCII?
Thanks in advance.
A.
Board footer
