For quite a while now I've been unable to use TDEsu to open utilities that require root access, e.g. TDM configuration. TDEsu freezes after I enter the root password and press Enter. When I run it from the command line I see
tdesu: WARNING: Daemon not safe (not sgid), not using it.
Looking at /opt/trinity/bin/tdesud, I saw that indeed, it was not sgid, so I set that bit; but it still hangs, albeit without the message. I see that there are four programs associated with this function:
-rwxr-xr-x 1 root root 59912 2019-03-18 15:53:08 /opt/trinity/bin/tdesu -rwxr-xr-x 1 root root 14544 2019-03-18 15:37:31 /opt/trinity/bin/tdesu_stub -rwxr-sr-x 1 root root 55440 2019-03-18 15:53:08 /opt/trinity/bin/tdesud -rwxr-xr-x 1 root root 72200 2019-03-19 15:10:26 /opt/trinity/bin/tdesudo
Should other bits be set for one or more of these? Is there a missing entry in /etc/group? What else should I look for? N.B. I have tried reinstalling the package containing TDEsu, but that hasn't helped.
Leslie
On Sun, 21 Jul 2019 14:14:48 -0500 J Leslie Turriff jlturriff@mail.com wrote:
I see that there are four programs associated with this function:
-rwxr-xr-x 1 root root 59912 2019-03-18 15:53:08 /opt/trinity/bin/tdesu -rwxr-xr-x 1 root root 14544 2019-03-18 15:37:31 /opt/trinity/bin/tdesu_stub -rwxr-sr-x 1 root root 55440 2019-03-18 15:53:08 /opt/trinity/bin/tdesud -rwxr-xr-x 1 root root 72200 2019-03-19 15:10:26 /opt/trinity/bin/tdesudo
Should other bits be set for one or more of these? Is there a missing entry in /etc/group? What else should I look for?
My setup's older, but I have:
-rwxr-xr-x 1 root root 56952 Dec 29 2017 /usr/trinity/14/bin/tdesu -rwxr-s--x 1 root nogroup 60440 Dec 29 2017 /usr/trinity/14/bin/tdesud -rwxr-xr-x 1 root root 14832 May 22 2018 /usr/trinity/14/bin/tdesu_stub
And everything works. I'd try unsetting the user read bit on tdesud first, and see if that helps.
E. Liddell
On Sun July 21 2019 12:14:48 J Leslie Turriff wrote:
For quite a while now I've been unable to use TDEsu to open utilities that require root access, e.g. TDM configuration. TDEsu freezes after I enter the root password and press Enter.
I see only one problem with your file permissions. tdesud should be setgrp in the nogroup group, not the root group.
tdesu is not designed for command line use. It is a graphical interface which uses /bin/su behind the scenes.
Does su (or sudo) work for you from the command line?
What happens if you click - T-menu / Trinity Control Center / System Administration / Monitor and Display - and enter your root password?
--Mike
On 2019-07-21 18:22:10 Mike Bird wrote:
On Sun July 21 2019 12:14:48 J Leslie Turriff wrote:
For quite a while now I've been unable to use TDEsu to open utilities that require root access, e.g. TDM configuration. TDEsu freezes after I enter the root password and press Enter.
I see only one problem with your file permissions. tdesud should be setgrp in the nogroup group, not the root group.
tdesu is not designed for command line use. It is a graphical interface which uses /bin/su behind the scenes.
Does su (or sudo) work for you from the command line?
What happens if you click - T-menu / Trinity Control Center / System Administration / Monitor and Display - and enter your root password?
--Mike
I only issued the tdesu call from the command line to see if there were any error messages from it. my command was tdesu -u root -c yast2 su and sudo both work; they do not depend on any Trinity components. The same problem occurs if I try to invoke any component of kControl that requires the root password. The TDEsu dialog opens, but after entering the password it locks up.
After changing the group ownership and adding the sgid bit to tdesud, the same thing happens.
On Sun July 21 2019 19:02:56 J Leslie Turriff wrote:
The same problem occurs if I try to invoke any component of kControl that requires the root password. The TDEsu dialog opens, but after entering the password it locks up.
(1) What does the relevant portion of your "ps fax" look like before and after entering your password?
(2) What is the nature of the lock up? Do you have to reboot to proceed? Can you close the TDEsu window or did it close when you typed enter or clicked OK after typing the password?
--Mike
On 2019-07-23 17:40:35 Mike Bird wrote:
On Sun July 21 2019 19:02:56 J Leslie Turriff wrote:
The same problem occurs if I try to invoke any component of kControl that requires the root password. The TDEsu dialog opens, but after entering the password it locks up.
(1) What does the relevant portion of your "ps fax" look like before and after entering your password?
Before: @20:00:26,leslie@pinto ~ $ ps fax|grep tdesu 3201 ? S 0:00 /opt/trinity/bin/tdesud 12631 pts/2 S+ 0:00 | | _ grep --color=auto tdesu 12497 ? SL 0:00 _ tdesu -u root -c /sbin/yast2 8182 ? S 0:00 /opt/trinity/bin/tdesud
After: @20:00:44,leslie@pinto ~ $ ps fax|grep tdesu 3201 ? S 0:00 /opt/trinity/bin/tdesud 13595 pts/2 S+ 0:00 | | _ grep --color=auto tdesu 12497 ? SL 0:00 _ tdesu -u root -c /sbin/yast2 13443 pts/22 Ss+ 0:00 _ /usr/bin/X11/su root -c /opt/trinity/bin/tdesu_stub - 8182 ? S 0:00 /opt/trinity/bin/tdesud
(2) What is the nature of the lock up? Do you have to reboot to proceed? Can you close the TDEsu window or did it close when you typed enter or clicked OK after typing the password?
After typing in the root password and pressing enter, the TDEsu window becomes non-responsive, though it can be moved around the desktop; if another window overlaps it and is then moved away it does not refresh. From the command line I can kill it with kill -9 <pid>; e.g., kill -9 12497 for the above instance.
Leslie
--Mike
To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On Tue July 23 2019 18:08:43 J Leslie Turriff wrote:
Before: @20:00:26,leslie@pinto ~ $ ps fax|grep tdesu 3201 ? S 0:00 /opt/trinity/bin/tdesud 12631 pts/2 S+ 0:00 | | _ grep --color=auto tdesu 12497 ? SL 0:00 _ tdesu -u root -c /sbin/yast2 8182 ? S 0:00 /opt/trinity/bin/tdesud
After: @20:00:44,leslie@pinto ~ $ ps fax|grep tdesu 3201 ? S 0:00 /opt/trinity/bin/tdesud 13595 pts/2 S+ 0:00 | | _ grep --color=auto tdesu 12497 ? SL 0:00 _ tdesu -u root -c /sbin/yast2 13443 pts/22 Ss+ 0:00 _ /usr/bin/X11/su root -c /opt/trinity/bin/tdesu_stub - 8182 ? S 0:00 /opt/trinity/bin/tdesud
Could be that yast2 isn't playing well with TDE. Sorry, I can't help you there as I'm running Debian Buster. Can you replicate this with something TDE running under tdesu, e.g. Monitor and Display:
21724 ? SL 0:00 _ tdesu -u root -c /opt/trinity/bin/tdecmshell displayconfig 21850 pts/13 Ss+ 0:00 _ /bin/su root -c /opt/trinity/bin/tdesu_stub - 21851 pts/13 S+ 0:00 _ /opt/trinity/bin/tdesu_stub 21854 ? Ss 0:00 _ sh -c /opt/trinity/bin/tdecmshell displayconfig 21855 ? S 0:00 _ /bin/sh /opt/trinity/bin/tdecmshell displayconfig 21856 ? S 0:00 _ /opt/trinity/bin/tdecmshell.real displayconfig
--Mike
On 2019-07-23 20:32:32 Mike Bird wrote:
On Tue July 23 2019 18:08:43 J Leslie Turriff wrote:
Before: @20:00:26,leslie@pinto ~ $ ps fax|grep tdesu 3201 ? S 0:00 /opt/trinity/bin/tdesud 12631 pts/2 S+ 0:00 | | _ grep --color=auto tdesu 12497 ? SL 0:00 _ tdesu -u root -c /sbin/yast2 8182 ? S 0:00 /opt/trinity/bin/tdesud
After: @20:00:44,leslie@pinto ~ $ ps fax|grep tdesu 3201 ? S 0:00 /opt/trinity/bin/tdesud 13595 pts/2 S+ 0:00 | | _ grep --color=auto tdesu 12497 ? SL 0:00 _ tdesu -u root -c /sbin/yast2 13443 pts/22 Ss+ 0:00 _ /usr/bin/X11/su root -c /opt/trinity/bin/tdesu_stub - 8182 ? S 0:00 /opt/trinity/bin/tdesud
Could be that yast2 isn't playing well with TDE. Sorry, I can't help you there as I'm running Debian Buster. Can you replicate this with something TDE running under tdesu, e.g. Monitor and Display:
The issue also occurs with Control Center, if I try to use any of the components that require administrator access, e.g. font management or TDM settings, so it has nothing to do with YaST; it's just that I use YaST a lot more than Control Center...
21724 ? SL 0:00 _ tdesu -u root -c /opt/trinity/bin/tdecmshell displayconfig 21850 pts/13 Ss+ 0:00 _ /bin/su root -c /opt/trinity/bin/tdesu_stub - 21851 pts/13 S+ 0:00 _ /opt/trinity/bin/tdesu_stub 21854 ? Ss 0:00 _ sh -c /opt/trinity/bin/tdecmshell displayconfig 21855 ? S 0:00 _ /bin/sh /opt/trinity/bin/tdecmshell displayconfig 21856 ? S 0:00 _ /opt/trinity/bin/tdecmshell.real displayconfig
--Mike
To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On Tue July 23 2019 23:47:16 J Leslie Turriff wrote:
The issue also occurs with Control Center, if I try to use any of the components that require administrator access, e.g. font management or TDM settings, so it has nothing to do with YaST; it's just that I use YaST a lot more than Control Center...
If you enter your root password and then run "ps ufax" are your su and tdesu_stub and their children running as root or as your user?
--Mike
On 2019-07-24 02:57:18 Mike Bird wrote:
On Tue July 23 2019 23:47:16 J Leslie Turriff wrote:
The issue also occurs with Control Center, if I try to use any of the components that require administrator access, e.g. font management or TDM settings, so it has nothing to do with YaST; it's just that I use YaST a lot more than Control Center...
If you enter your root password and then run "ps ufax" are your su and tdesu_stub and their children running as root or as your user?
--Mike
ps ufax shows this:
$ ps ufax | grep tdesu leslie 26741 0.2 0.0 197348 31348 pts/28 SL 01:33 0:00 | | _
tdesu -u root -c yast2
root 26909 0.0 0.0 111252 5680 pts/22 Ss+ 01:33 0:00 | | |
_ /usr/bin/X11/su root -c /opt/trinity/bin/tdesu_stub -
leslie 27066 0.0 0.0 8692 908 pts/28 S+ 01:34 0:00 | | _
grep --color=auto tdesu
leslie 3201 0.0 0.0 147552 6208 ? S Jul21
0:00 /opt/trinity/bin/tdesud
On Wed July 24 2019 23:36:42 J Leslie Turriff wrote:
$ ps ufax | grep tdesu
Unfortunately that doesn't show the user running /usr/bin/X11/su.
However it seems possible that your su has lost its suid bit.
Please do "ls -dl /usr/bin/X11 /usr/bin/X11/su /bin/su /usr/bin/su". (probably one of those files will be missing but that's OK.)
--Mike
On Thursday 25 July 2019 03:01:17 Mike Bird wrote:
On Wed July 24 2019 23:36:42 J Leslie Turriff wrote:
$ ps ufax | grep tdesu
Unfortunately that doesn't show the user running /usr/bin/X11/su.
However it seems possible that your su has lost its suid bit.
Please do "ls -dl /usr/bin/X11 /usr/bin/X11/su /bin/su /usr/bin/su". (probably one of those files will be missing but that's OK.)
--Mike
With all the hoorah about tdesu, I just tried it, found it worthless. It asks for the root password on a system that has no root passwd, I do everything that needs root with a sudo. Sigh.
Cheers, Gene Heskett
On Thu July 25 2019 00:47:10 Gene Heskett wrote:
With all the hoorah about tdesu, I just tried it, found it worthless. It asks for the root password on a system that has no root passwd, I do everything that needs root with a sudo. Sigh.
The TDE frontend to sudo is tdesudo in package tdesudo-trinity.
--Mike
On Thursday 25 July 2019 08:44:29 Mike Bird wrote:
On Thu July 25 2019 00:47:10 Gene Heskett wrote:
With all the hoorah about tdesu, I just tried it, found it worthless. It asks for the root password on a system that has no root passwd, I do everything that needs root with a sudo. Sigh.
The TDE frontend to sudo is tdesudo in package tdesudo-trinity.
--Mike
Stretch install, TDE R14-0.latest.
gene@coyote:/etc/cron.daily$ tdesudo synaptic tdesudo: error while loading shared libraries: libtdecore.so.14: cannot open shared object file: No such file or directory gene@coyote:/etc/cron.daily$
I rest my case, ;-) as neither is usable on a passwd-less root system. Called from the menu, it asks for root pw, but a synaptic-pkexec properly asks for my pw.
There are several examples of this failure in the tde menus, no way to run root requiring stuff from the menu's. Gets frustrating at times as there seems to be no consistency for the cli work-a-round's. Some need a sudo, some need a gksudo. Twould be nice if it was fixed. :)
To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Cheers, Gene Heskett
On Thu July 25 2019 10:51:52 Gene Heskett wrote:
gene@coyote:/etc/cron.daily$ tdesudo synaptic tdesudo: error while loading shared libraries: libtdecore.so.14: cannot open shared object file: No such file or directory
Hi Gene,
I have no idea how you can have TDE installed and running without one of the most important TDE libraries. Perhaps a path problem.
Meanwhile have you considered setting a root password? Requiring a key instead of a password for ssh root login makes sense. And requiring sudo on systems with multiple admins with different privilege levels makes sense. But I don't see why you are making things hard for yourself on your systems but not having a root password.
--Mike
On 2019-07-25 15:17:27 Mike Bird wrote:
On Thu July 25 2019 10:51:52 Gene Heskett wrote:
gene@coyote:/etc/cron.daily$ tdesudo synaptic tdesudo: error while loading shared libraries: libtdecore.so.14: cannot open shared object file: No such file or directory
Hi Gene,
I have no idea how you can have TDE installed and running without one of the most important TDE libraries. Perhaps a path problem.
Meanwhile have you considered setting a root password? Requiring a key instead of a password for ssh root login makes sense. And requiring sudo on systems with multiple admins with different privilege levels makes sense. But I don't see why you are making things hard for yourself on your systems but not having a root password.
--Mike
Many of the distros that are aimed at the non-technical user make it difficult to set a root password, or at least to find instructions for doing so.
Leslie
On Thursday 25 July 2019 16:17:27 Mike Bird wrote:
On Thu July 25 2019 10:51:52 Gene Heskett wrote:
gene@coyote:/etc/cron.daily$ tdesudo synaptic tdesudo: error while loading shared libraries: libtdecore.so.14: cannot open shared object file: No such file or directory
Hi Gene,
I have no idea how you can have TDE installed and running without one of the most important TDE libraries. Perhaps a path problem.
No, well not intentional. Its looking, or trying to, at /opt/trinity/lib64 but there's only a lib dir. Maybe this explains other stuff thats wonky too. Like my index problems with kmail a couple months back, etc etc.
This was a 32 bit install until I updated to stretch for amd64 on this machine.
So how do I convert an uptodate r14 install from 32 bit to 64 bit?
here's the trinity.list # Trinity repositories deb http://mirror.ppa.trinitydesktop.org/trinity/trinity-r14.0.0/debian/ stretch main deb http://mirror.ppa.trinitydesktop.org/trinity/trinity-builddeps-r14.0.0/debia... stretch main
So I don't see an amd64 spec.
Meanwhile have you considered setting a root password? Requiring a key instead of a password for ssh root login makes sense. And requiring sudo on systems with multiple admins with different privilege levels makes sense. But I don't see why you are making things hard for yourself on your systems but not having a root password.
1. I'm the only active, warm blooded user 1000. There are of course other "users" but most of that is just sandboxing.
And 2, debian has never been real fond of pw's for root.
--Mike
To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Cheers, Gene Heskett
On Thursday 25 July 2019 20:40:45 Gene Heskett wrote:
On Thursday 25 July 2019 16:17:27 Mike Bird wrote:
On Thu July 25 2019 10:51:52 Gene Heskett wrote:
gene@coyote:/etc/cron.daily$ tdesudo synaptic tdesudo: error while loading shared libraries: libtdecore.so.14: cannot open shared object file: No such file or directory
Hi Gene,
I have no idea how you can have TDE installed and running without one of the most important TDE libraries. Perhaps a path problem.
No, well not intentional. Its looking, or trying to, at /opt/trinity/lib64 but there's only a lib dir. Maybe this explains other stuff thats wonky too. Like my index problems with kmail a couple months back, etc etc.
This was a 32 bit install until I updated to stretch for amd64 on this machine.
So how do I convert an uptodate r14 install from 32 bit to 64 bit?
here's the trinity.list # Trinity repositories deb http://mirror.ppa.trinitydesktop.org/trinity/trinity-r14.0.0/debian/ stretch main deb http://mirror.ppa.trinitydesktop.org/trinity/trinity-builddeps-r14.0.0/debi an/ stretch main
So I don't see an amd64 spec.
Meanwhile have you considered setting a root password? Requiring a key instead of a password for ssh root login makes sense. And requiring sudo on systems with multiple admins with different privilege levels makes sense. But I don't see why you are making things hard for yourself on your systems but not having a root password.
- I'm the only active, warm blooded user 1000. There are of course
other "users" but most of that is just sandboxing.
And 2, debian has never been real fond of pw's for root.
Cheers, Gene Heskett
I'm with Gene on part 1 of this question: no root password for a single user system. I don't see any real purpose in making oneself log in as root to perform administrative tasks; it is enough to use sudo or su, so long as the admin is the only user, and the password is very secure. (If somebody wants to take 20 million years to brute-force my password, go right ahead, as it isn't written down anywhere, and it is really long, and has lots of messy characters. Oh, and I also alternate among 4 different complex passwords.) Of course, quantum computers will change all this, but maybe by then we'll also have some kind of comparable quantum encryption.
However, part 2: tdesu is very useful for getting things done; and it never makes me log in as root. To do that, you have to set up your system for root logins, so it seems to me that you must have done this either on the original installation (one of the questions asked by the installer), or maybe you did it under the Trinity Control Center:
TCC / System Administration / Login Manager / Convenience / Miscellaneous / Allow Root Login
I never clicked that box, but maybe Gene did.
Bill
On Friday 26 July 2019 00:17:21 William Morder via trinity-users wrote:
On Thursday 25 July 2019 20:40:45 Gene Heskett wrote:
On Thursday 25 July 2019 16:17:27 Mike Bird wrote:
On Thu July 25 2019 10:51:52 Gene Heskett wrote:
gene@coyote:/etc/cron.daily$ tdesudo synaptic tdesudo: error while loading shared libraries: libtdecore.so.14: cannot open shared object file: No such file or directory
Hi Gene,
I have no idea how you can have TDE installed and running without one of the most important TDE libraries. Perhaps a path problem.
No, well not intentional. Its looking, or trying to, at /opt/trinity/lib64 but there's only a lib dir. Maybe this explains other stuff thats wonky too. Like my index problems with kmail a couple months back, etc etc.
This was a 32 bit install until I updated to stretch for amd64 on this machine.
So how do I convert an uptodate r14 install from 32 bit to 64 bit?
here's the trinity.list # Trinity repositories deb http://mirror.ppa.trinitydesktop.org/trinity/trinity-r14.0.0/debian/ stretch main deb http://mirror.ppa.trinitydesktop.org/trinity/trinity-builddeps-r14.0 .0/debi an/ stretch main
So I don't see an amd64 spec.
Meanwhile have you considered setting a root password? Requiring a key instead of a password for ssh root login makes sense. And requiring sudo on systems with multiple admins with different privilege levels makes sense. But I don't see why you are making things hard for yourself on your systems but not having a root password.
- I'm the only active, warm blooded user 1000. There are of course
other "users" but most of that is just sandboxing.
And 2, debian has never been real fond of pw's for root.
Cheers, Gene Heskett
I'm with Gene on part 1 of this question: no root password for a single user system. I don't see any real purpose in making oneself log in as root to perform administrative tasks; it is enough to use sudo or su, so long as the admin is the only user, and the password is very secure. (If somebody wants to take 20 million years to brute-force my password, go right ahead, as it isn't written down anywhere, and it is really long, and has lots of messy characters. Oh, and I also alternate among 4 different complex passwords.) Of course, quantum computers will change all this, but maybe by then we'll also have some kind of comparable quantum encryption.
However, part 2: tdesu is very useful for getting things done; and it never makes me log in as root. To do that, you have to set up your system for root logins, so it seems to me that you must have done this either on the original installation (one of the questions asked by the installer), or maybe you did it under the Trinity Control Center:
TCC / System Administration / Login Manager / Convenience / Miscellaneous / Allow Root Login
I never clicked that box, but maybe Gene did.
Bill
Nope. I don't allow an ssh login anyplace on my home network as root. That makes moving stuff that needs root a 2 step process, but thats ok, mc can handle both steps, just takes two sessions to do it.
To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Cheers, Gene Heskett
No, well not intentional. Its looking, or trying to, at /opt/trinity/lib64 but there's only a lib dir. Maybe this explains other stuff thats wonky too. Like my index problems with kmail a couple months back, etc etc.
Hey Gene, if it's not finding libtdecore, it's game over, that's why it's not working. You can symlink a lib64 to the lib directory as a workaround for now until you get your packages in sync or whatever the cause of this is.
cd /opt/trinity ln -s lib lib64
On Fri, Jul 26, 2019 at 7:52 AM Gene Heskett gheskett@shentel.net wrote:
On Friday 26 July 2019 00:17:21 William Morder via trinity-users wrote:
On Thursday 25 July 2019 20:40:45 Gene Heskett wrote:
On Thursday 25 July 2019 16:17:27 Mike Bird wrote:
On Thu July 25 2019 10:51:52 Gene Heskett wrote:
gene@coyote:/etc/cron.daily$ tdesudo synaptic tdesudo: error while loading shared libraries: libtdecore.so.14: cannot open shared object file: No such file or directory
Hi Gene,
I have no idea how you can have TDE installed and running without one of the most important TDE libraries. Perhaps a path problem.
No, well not intentional. Its looking, or trying to, at /opt/trinity/lib64 but there's only a lib dir. Maybe this explains other stuff thats wonky too. Like my index problems with kmail a couple months back, etc etc.
This was a 32 bit install until I updated to stretch for amd64 on this machine.
So how do I convert an uptodate r14 install from 32 bit to 64 bit?
here's the trinity.list # Trinity repositories deb http://mirror.ppa.trinitydesktop.org/trinity/trinity-r14.0.0/debian/ stretch main deb http://mirror.ppa.trinitydesktop.org/trinity/trinity-builddeps-r14.0 .0/debi an/ stretch main
So I don't see an amd64 spec.
Meanwhile have you considered setting a root password? Requiring a key instead of a password for ssh root login makes sense. And requiring sudo on systems with multiple admins with different privilege levels makes sense. But I don't see why you are making things hard for yourself on your systems but not having a root password.
- I'm the only active, warm blooded user 1000. There are of course
other "users" but most of that is just sandboxing.
And 2, debian has never been real fond of pw's for root.
Cheers, Gene Heskett
I'm with Gene on part 1 of this question: no root password for a single user system. I don't see any real purpose in making oneself log in as root to perform administrative tasks; it is enough to use sudo or su, so long as the admin is the only user, and the password is very secure. (If somebody wants to take 20 million years to brute-force my password, go right ahead, as it isn't written down anywhere, and it is really long, and has lots of messy characters. Oh, and I also alternate among 4 different complex passwords.) Of course, quantum computers will change all this, but maybe by then we'll also have some kind of comparable quantum encryption.
However, part 2: tdesu is very useful for getting things done; and it never makes me log in as root. To do that, you have to set up your system for root logins, so it seems to me that you must have done this either on the original installation (one of the questions asked by the installer), or maybe you did it under the Trinity Control Center:
TCC / System Administration / Login Manager / Convenience / Miscellaneous / Allow Root Login
I never clicked that box, but maybe Gene did.
Bill
Nope. I don't allow an ssh login anyplace on my home network as root. That makes moving stuff that needs root a 2 step process, but thats ok, mc can handle both steps, just takes two sessions to do it.
To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Cheers, Gene Heskett
"There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page http://geneslinuxbox.net:6309/gene
To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On Friday 26 July 2019 19:25:59 Snidely Whiplash wrote:
No, well not intentional. Its looking, or trying to, at /opt/trinity/lib64 but there's only a lib dir. Maybe this explains other stuff thats wonky too. Like my index problems with kmail a couple months back, etc etc.
Hey Gene, if it's not finding libtdecore, it's game over, that's why it's not working. You can symlink a lib64 to the lib directory as a workaround for now until you get your packages in sync or whatever the cause of this is.
cd /opt/trinity ln -s lib lib64
Done. But it strikes me there ought to be a better way. 99% of it is working fine. I'll see what works now that didn't before.
Thanks.
On Fri, Jul 26, 2019 at 7:52 AM Gene Heskett gheskett@shentel.net
wrote:
On Friday 26 July 2019 00:17:21 William Morder via trinity-users
wrote:
On Thursday 25 July 2019 20:40:45 Gene Heskett wrote:
On Thursday 25 July 2019 16:17:27 Mike Bird wrote:
On Thu July 25 2019 10:51:52 Gene Heskett wrote:
gene@coyote:/etc/cron.daily$ tdesudo synaptic tdesudo: error while loading shared libraries: libtdecore.so.14: cannot open shared object file: No such file or directory
Hi Gene,
I have no idea how you can have TDE installed and running without one of the most important TDE libraries. Perhaps a path problem.
No, well not intentional. Its looking, or trying to, at /opt/trinity/lib64 but there's only a lib dir. Maybe this explains other stuff thats wonky too. Like my index problems with kmail a couple months back, etc etc.
This was a 32 bit install until I updated to stretch for amd64 on this machine.
So how do I convert an uptodate r14 install from 32 bit to 64 bit?
here's the trinity.list # Trinity repositories deb http://mirror.ppa.trinitydesktop.org/trinity/trinity-r14.0.0/deb ian/ stretch main deb http://mirror.ppa.trinitydesktop.org/trinity/trinity-builddeps-r 14.0 .0/debi an/ stretch main
So I don't see an amd64 spec.
Meanwhile have you considered setting a root password? Requiring a key instead of a password for ssh root login makes sense. And requiring sudo on systems with multiple admins with different privilege levels makes sense. But I don't see why you are making things hard for yourself on your systems but not having a root password.
- I'm the only active, warm blooded user 1000. There are of
course other "users" but most of that is just sandboxing.
And 2, debian has never been real fond of pw's for root.
Cheers, Gene Heskett
I'm with Gene on part 1 of this question: no root password for a single user system. I don't see any real purpose in making oneself log in as root to perform administrative tasks; it is enough to use sudo or su, so long as the admin is the only user, and the password is very secure. (If somebody wants to take 20 million years to brute-force my password, go right ahead, as it isn't written down anywhere, and it is really long, and has lots of messy characters. Oh, and I also alternate among 4 different complex passwords.) Of course, quantum computers will change all this, but maybe by then we'll also have some kind of comparable quantum encryption.
However, part 2: tdesu is very useful for getting things done; and it never makes me log in as root. To do that, you have to set up your system for root logins, so it seems to me that you must have done this either on the original installation (one of the questions asked by the installer), or maybe you did it under the Trinity Control Center:
TCC / System Administration / Login Manager / Convenience / Miscellaneous / Allow Root Login
I never clicked that box, but maybe Gene did.
Bill
Nope. I don't allow an ssh login anyplace on my home network as root. That makes moving stuff that needs root a 2 step process, but thats ok, mc can handle both steps, just takes two sessions to do it.
--- To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Cheers, Gene Heskett
"There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis Genes Web page http://geneslinuxbox.net:6309/gene
- To unsubscribe, e-mail:
trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Cheers, Gene Heskett
Gene Heskett wrote:
Done. But it strikes me there ought to be a better way. 99% of it is working fine. I'll see what works now that didn't before.
Thanks.
No idea why you would have so many issues with upgrades and installation, but your spirit is most amazing - never give up! the issue with the lib is I think because you jumped over from 8 to 10 or something like this.
My advise is follow the stream. In the linux community it mostly works for you. This is like swarm intelligence. Customize here and there less as possible and write logs, so that you do not forget. If the list of logs is more than one or two printable pages - forget it ... too much customization.
regards
cd /opt/trinity ln -s lib lib64
Done. But it strikes me there ought to be a better way. 99% of it is working fine. I'll see what works now that didn't before.
That's actually something I do before the first "make install". I first create /opt/trinity and lib, then I symlink a lib64 before I build tqt-interface. Why? Because I had a sneaking suspicion that something like that might happen with one or more of those packages, so I've been doing it all along. It shouldn't if you're installing binary packages though, that would be pretty sloppy of a maintainer to be inconsistent, unless they weren't specifically for your distro, or mixed.
I actually don't like "lib64" on a non-multilib system. There's just no need for that shit, but it's become a convention and a mixed bag at that. I don't want to have to remember to specify libdirsuffix for every build.
Arch Linux (and derivatives) makes lib64 the symlink to lib, and 32 bit stuff goes in lib32.
On 2019-07-25 23:17:21 William Morder via trinity-users wrote:
On Thursday 25 July 2019 20:40:45 Gene Heskett wrote:
On Thursday 25 July 2019 16:17:27 Mike Bird wrote:
On Thu July 25 2019 10:51:52 Gene Heskett wrote:
gene@coyote:/etc/cron.daily$ tdesudo synaptic tdesudo: error while loading shared libraries: libtdecore.so.14: cannot open shared object file: No such file or directory
Hi Gene,
I have no idea how you can have TDE installed and running without one of the most important TDE libraries. Perhaps a path problem.
No, well not intentional. Its looking, or trying to, at /opt/trinity/lib64 but there's only a lib dir. Maybe this explains other stuff thats wonky too. Like my index problems with kmail a couple months back, etc etc.
This was a 32 bit install until I updated to stretch for amd64 on this machine.
So how do I convert an uptodate r14 install from 32 bit to 64 bit?
here's the trinity.list # Trinity repositories deb http://mirror.ppa.trinitydesktop.org/trinity/trinity-r14.0.0/debian/ stretch main deb http://mirror.ppa.trinitydesktop.org/trinity/trinity-builddeps-r14.0.0/de bi an/ stretch main
So I don't see an amd64 spec.
Meanwhile have you considered setting a root password? Requiring a key instead of a password for ssh root login makes sense. And requiring sudo on systems with multiple admins with different privilege levels makes sense. But I don't see why you are making things hard for yourself on your systems but not having a root password.
- I'm the only active, warm blooded user 1000. There are of course
other "users" but most of that is just sandboxing.
And 2, debian has never been real fond of pw's for root.
Cheers, Gene Heskett
I'm with Gene on part 1 of this question: no root password for a single user system. I don't see any real purpose in making oneself log in as root to perform administrative tasks; it is enough to use sudo or su, so long as the admin is the only user, and the password is very secure. (If somebody wants to take 20 million years to brute-force my password, go right ahead, as it isn't written down anywhere, and it is really long, and has lots of messy characters. Oh, and I also alternate among 4 different complex passwords.) Of course, quantum computers will change all this, but maybe by then we'll also have some kind of comparable quantum encryption.
However, part 2: tdesu is very useful for getting things done; and it never makes me log in as root. To do that, you have to set up your system for root logins, so it seems to me that you must have done this either on the original installation (one of the questions asked by the installer), or maybe you did it under the Trinity Control Center:
TCC / System Administration / Login Manager / Convenience / Miscellaneous / Allow Root Login
I never clicked that box, but maybe Gene did.
Bill
Re 1) since OpenSuSE's philosophy has always been to set and use a root password, that has always been what I am used to. 2) Certainly TDEsu (and especially the KDE3 equivalent) used to work seamlessly, though the last two times I installed Trinity I had to figure out the necessary steps to defeat its Nanny treatment of the root password issue (which presumably it has inherited from the Ubuntu philosophy).
Leslie
On 2019-07-25 02:47:10 Gene Heskett wrote:
On Thursday 25 July 2019 03:01:17 Mike Bird wrote:
On Wed July 24 2019 23:36:42 J Leslie Turriff wrote:
$ ps ufax | grep tdesu
Unfortunately that doesn't show the user running /usr/bin/X11/su.
However it seems possible that your su has lost its suid bit.
Please do "ls -dl /usr/bin/X11 /usr/bin/X11/su /bin/su /usr/bin/su". (probably one of those files will be missing but that's OK.)
--Mike
With all the hoorah about tdesu, I just tried it, found it worthless. It asks for the root password on a system that has no root passwd, I do everything that needs root with a sudo. Sigh.
Cheers, Gene Heskett
Some distros (e.g. Ubuntu) discourage use of su, others (e.g. OpenSuSE) don't.
On 2019-07-25 02:01:17 Mike Bird wrote:
On Wed July 24 2019 23:36:42 J Leslie Turriff wrote:
$ ps ufax | grep tdesu
Unfortunately that doesn't show the user running /usr/bin/X11/su.
However it seems possible that your su has lost its suid bit.
Please do "ls -dl /usr/bin/X11 /usr/bin/X11/su /bin/su /usr/bin/su". (probably one of those files will be missing but that's OK.)
--Mike
# ls -dl /usr/bin/X11 /usr/bin/X11/su /bin/su /usr/bin/su lrwxrwxrwx 1 root root 11 2018-07-26 11:11 /bin/su -> /usr/bin/su lrwxrwxrwx 1 root root 1 2018-02-19 11:11 /usr/bin/X11 -> . -rwsr-xr-x 1 root root 43K 2018-07-26 11:11 /usr/bin/X11/su -rwsr-xr-x 1 root root 43K 2018-07-26 11:11 /usr/bin/su
On Thu July 25 2019 18:51:50 J Leslie Turriff wrote:
# ls -dl /usr/bin/X11 /usr/bin/X11/su /bin/su /usr/bin/su lrwxrwxrwx 1 root root 11 2018-07-26 11:11 /bin/su -> /usr/bin/su lrwxrwxrwx 1 root root 1 2018-02-19 11:11 /usr/bin/X11 -> . -rwsr-xr-x 1 root root 43K 2018-07-26 11:11 /usr/bin/X11/su -rwsr-xr-x 1 root root 43K 2018-07-26 11:11 /usr/bin/su
Sorry, I can't see what is wrong. I hope somebody smarter than I can help you.
--Mike
On 07/21/2019 09:02 PM, J Leslie Turriff wrote:
On 2019-07-21 18:22:10 Mike Bird wrote:
On Sun July 21 2019 12:14:48 J Leslie Turriff wrote:
For quite a while now I've been unable to use TDEsu to open utilities that require root access, e.g. TDM configuration. TDEsu freezes after I enter the root password and press Enter.
I see only one problem with your file permissions. tdesud should be setgrp in the nogroup group, not the root group.
tdesu is not designed for command line use. It is a graphical interface which uses /bin/su behind the scenes.
Does su (or sudo) work for you from the command line?
What happens if you click - T-menu / Trinity Control Center / System Administration / Monitor and Display - and enter your root password?
--Mike
I only issued the tdesu call from the command line to see if there were any error messages from it. my command was tdesu -u root -c yast2 su and sudo both work; they do not depend on any Trinity components. The same problem occurs if I try to invoke any component of kControl that requires the root password. The TDEsu dialog opens, but after entering the password it locks up.
After changing the group ownership and adding the sgid bit to tdesud, the same thing happens.
I have a VERY OLD note that KDE/TDE defaults to using su instead of sudo and that can cause issues in some instances. You can change kdesu to use sudo instead with the following:
kwriteconfig --file kdesurc --group super-user-command --key super-user-command sudo
(you change back by using su instead of sudo in the above)
I have not had trouble in the past few years, but it is worth a test.
On 2019-07-24 19:23:32 David C. Rankin wrote:
On 07/21/2019 09:02 PM, J Leslie Turriff wrote:
On 2019-07-21 18:22:10 Mike Bird wrote:
On Sun July 21 2019 12:14:48 J Leslie Turriff wrote:
For quite a while now I've been unable to use TDEsu to open utilities that require root access, e.g. TDM configuration. TDEsu freezes after I enter the root password and press Enter.
I see only one problem with your file permissions. tdesud should be setgrp in the nogroup group, not the root group.
tdesu is not designed for command line use. It is a graphical interface which uses /bin/su behind the scenes.
Does su (or sudo) work for you from the command line?
What happens if you click - T-menu / Trinity Control Center / System Administration / Monitor and Display - and enter your root password?
--Mike
I only issued the tdesu call from the command line to see if there were any error messages from it. my command was tdesu -u root -c yast2 su and sudo both work; they do not depend on any Trinity components. The same problem occurs if I try to invoke any component of kControl that requires the root password. The TDEsu dialog opens, but after entering the password it locks up.
After changing the group ownership and adding the sgid bit to tdesud, the same thing happens.
I have a VERY OLD note that KDE/TDE defaults to using su instead of sudo and that can cause issues in some instances. You can change kdesu to use sudo instead with the following:
kwriteconfig --file kdesurc --group super-user-command --key super-user-command sudo
(you change back by using su instead of sudo in the above)
I have not had trouble in the past few years, but it is worth a test.
Because OpenSuSE, the distro I use, has traditionally used both su and sudo for system administration, many (most?) OpenSuSE users are not averse to using either or both of them; the distro seems to expect that su will be used for administration.
Leslie
On 07/25/2019 08:58 PM, J Leslie Turriff wrote:
Because OpenSuSE, the distro I use, has traditionally used both su and sudo for system administration, many (most?) OpenSuSE users are not averse to using either or both of them; the distro seems to expect that su will be used for administration.
:) yep, I've run SuSE since 7.0-Pro, when Mandrake begin to implode. On openSuSE you can also configure /etc/pam.d/su to allow member of the wheel group to su without a password -- that comes in hand for me (since I'm the only member of wheel) You can add:
auth sufficient pam_rootok.so auth sufficient pam_wheel.so trust use_uid
Take effect immediately (presuming you are a member of wheel -- which in 15.0 or 15.1 opensuse no longer creates by default unless a server install is selected -- just create it manually, and I gave it the traditional GID of 10, but in 15.0 it has a random GID.
On 2019-07-26 02:34:29 David C. Rankin wrote:
On 07/25/2019 08:58 PM, J Leslie Turriff wrote:
Because OpenSuSE, the distro I use, has traditionally used both su and sudo for system administration, many (most?) OpenSuSE users are not averse to using either or both of them; the distro seems to expect that su will be used for administration.
:) yep, I've run SuSE since 7.0-Pro, when Mandrake begin to implode. On
openSuSE you can also configure /etc/pam.d/su to allow member of the wheel group to su without a password -- that comes in hand for me (since I'm the only member of wheel) You can add:
auth sufficient pam_rootok.so auth sufficient pam_wheel.so trust use_uid
Take effect immediately (presuming you are a member of wheel -- which in 15.0 or 15.1 opensuse no longer creates by default unless a server install is selected -- just create it manually, and I gave it the traditional GID of 10, but in 15.0 it has a random GID.
I think that I'll try this. What, then, (if anything) should I put in the Command field of my menu entries for the YaST components? The original Trinity install had some sort of xdg prefix, which I removed, adding Run as a Different User (root) instead.
Leslie
On 07/27/2019 02:04 PM, J Leslie Turriff wrote:
I think that I'll try this. What, then, (if anything) should I put in the Command field of my menu entries for the YaST components? The original Trinity install had some sort of xdg prefix, which I removed, adding Run as a Different User (root) instead.
That's the beauty of it, you don't have to put anything in the kmenu entry. Mine has [x] run as different user checked -- but no username. Yast much check whether you have elevated privileges available automatically.
See below:
On 2019-07-26 02:34:29 David C. Rankin wrote:
On 07/25/2019 08:58 PM, J Leslie Turriff wrote:
Because OpenSuSE, the distro I use, has traditionally used both su and sudo for system administration, many (most?) OpenSuSE users are not averse to using either or both of them; the distro seems to expect that su will be used for administration.
:) yep, I've run SuSE since 7.0-Pro, when Mandrake begin to implode. On
openSuSE you can also configure /etc/pam.d/su to allow member of the wheel group to su without a password -- that comes in hand for me (since I'm the only member of wheel) You can add:
auth sufficient pam_rootok.so auth sufficient pam_wheel.so trust use_uid
Take effect immediately (presuming you are a member of wheel -- which in 15.0 or 15.1 opensuse no longer creates by default unless a server install is selected -- just create it manually, and I gave it the traditional GID of 10, but in 15.0 it has a random GID.
Hm. The first auth was already set, but after adding the second it wants me to enter the root password; is that the way it works for you? If so, it doesn't seem to provide a benefit to me. :-)
Leslie