Light-Debian-Core-Live-CD-Wheezy + Porteus-Wheezy

[fredx181]

Hi Toni,

Then logout and login and typing again in terminal save2flash does not ask for password and saves changes. See the picture

Can you explain that? It's really strange, at least "sudo save2flash" should be run (adding /usr/bin/save2flash to 'wheel' line causes only that you don't need to type password, still need to use sudo, right?)
I cannot reproduce what you got, btw, with wheel line in sudoers including save2flash, puppy added to group wheel and gsu line on top of save2flash I got this (see pictures):
Which is the behaviour I expect.

Fred

[saintless]

Hi, Fred.

This is what happens when you keep using yad for everything and you don't like my simple xterm solution If I use your gsu with yad I get the same result as you.
Try with /opt/bin/gsu insluded in Jwm version. Works for save2flash without sudo for me:

Code: Select all

#!/bin/sh 

if [ "`whoami`" != "root" ]; then 
xterm -T "gsu" -si -sb -fg white -bg SkyBlue4 -geometry 65x14 -e sudo "$@" 
else 
"$@" 
fi 

I leave you to decide what is better. Changing gsu to xterm solution in both versions or using yad gsu for both and you have more work with save2flash.

Edit: Attached archive with example scripts to activate/deactivate password on shutdown by removing/adding user to group wheel. I'm sure you can make them better if you prefer something different, Fred. We need to choose the same name and same menu entries for activating/deactivating password prompt in both DD versions.

Toni

[saintless]

Would be nice to have in the howto section.

Hi, Anikin.
I don't like the idea removing multiuser function but even if I do - It will not work anyway adding the information in howto thread.
We keep adding more and more user account extras in DebianDog like deactivating the password prompt on shutdown we discuss now with Fred.
We also modding the included packages preventing conflicts with official Debian packages and adding dependencies like sudo, gsu, gksu needed for user account. This will make them work not only in DD but in most Debian based systems using apt-get or synaptic.
This means after next DD update removing sudo or gsu will remove much more packages (like mount-wizard for example) just because sudo or gsu is added as dependency.
I'm afraid after removing sudo you will have to mod DebianDog packages in the future if you want to skip installing again sudo (or to skip installing dependencies like gsu, gksu, ktsuss).
With sure many official Debian and Ubuntu packages also have sudo as dependency and installing some of them with apt-get will install sudo anyway.

Toni

[anikin]

Hi Toni,

I don't disagree with you, my only concern is that a valuable piece of information will be lost in this huge thread. Something that even Google doesn't have easily available. Do a search and you'll get fragments at best. Maybe, adding a couple lines, like "do it at your own risk" plus your recommendations would be a better decision? Personally, I'm OK, I got what I wanted from you.

[fredx181]

Hi Toni,

This is what happens when you keep using yad for everything and you don't like my simple xterm solution Smile If I use your gsu with yad I get the same result as you.
.....

Ah, That explains it, I thought you had new gsu installed.

I thought that the best thing to do is changing gsu to make it behave exactly like sudo (checking if password is needed or not) which is a good thing anyway, I think.
So this way there's no need to change save2flash and gsu works with any command added to wheel line.
Also made some other useful changes IMO:
- shows message when password is empty (not only when wrong)
- improved "command not found" check.
Attached new gsu.tar.gz
Btw, the reason for the most that I don't like the "xterm gsu" is because the xterm window doesn't disappear after entering password, I've tried to accomplish that in the past, but with no success.

Edit: Attached archive with example scripts to activate/deactivate password on shutdown by removing/adding user to group wheel. I'm sure you can make them better if you prefer something different, Fred.

Thanks, Toni! I will look at it, maybe add some YAD dialogs

Fred

[saintless]

I thought that the best thing to do is changing gsu to make it behave exactly like sudo (checking if password is needed or not) which is a good thing anyway, I think.

Hi, Fred.
Quick test shows new gsu works the same way as xterm version. The deb in testing repository replaced with this new gsu.

Toni

[fredx181]

Edit; Post deleted, not important.

Fred

[fredx181]

Hi Toni,

Quick test shows new gsu works the same way as xterm version. The deb in testing repository replaced with this new gsu.

Just an idea:
This gives another, perhaps more simple and compatible option (for older DD versions also):
To make wheel line in /etc/sudoers like this:

Code: Select all

%wheel ALL= NOPASSWD: /sbin/shutdown, /sbin/reboot, /sbin/poweroff, /usr/bin/wmpoweroff, /usr/bin/wmreboot

Or maybe just:

Code: Select all

%wheel ALL= NOPASSWD: /sbin/shutdown, /sbin/halt, /usr/bin/wmpoweroff, /usr/bin/wmreboot

This way only gsu script and /etc/sudoers needs to be changed in new release (and adding wheel group), nothing else (not sure, it's late, need sleep now ).

Fred

[saintless]

Hi, Fred.

Yes, we can try to make poweroff without password simple as possible. I will test your suggestion later but I think /usr/bin/save2flash shoud be added also in sudoers. It will be good if we can skip editing wmpoweroff and wmreboot.

Edit: Yes, Fred. Seems to work well.
Fresh Jwm version, porteus-boot, changes on exit in save flolder /live/changes, xdm is active. Login as user puppy and install latest gsu deb package. Then:

Code: Select all

sudo groupadd wheel

Code: Select all

sudo visudo

Code: Select all

%wheel ALL= NOPASSWD: /sbin/shutdown, /sbin/reboot, /sbin/poweroff, /usr/bin/wmpoweroff, /usr/bin/wmreboot, /usr/bin/save2flash

Code: Select all

sudo adduser puppy wheel

Logout and login and I can shutdown, reboot, save2flash without password prompt.
It will work also for any older DD version. Nice

Toni

[saintless]

Hi, Fred.

I've tried menumaker and ffconvert on my full install and no problems.
Only for menumaker a warning that defaultbrowser is not found.

Although I couldn't reproduce the menumaker error you had I've removed a section (mostly about default-browser)
So it's just a guess but maybe it helps.
Attached menumaker.tar.gz

Solved at Last
Nothing to do with defaultbrowser line but this is the real problem in menumaker:

Code: Select all

#define gtkdialog
if [ "`which gtkdialog4`" ]; then
	GTKDIALOG=gtkdialog4
elif [ "`which gtkdialog3`" ]; then
	GTKDIALOG=gtkdialog3
else
	GTKDIALOG=gtkdialog
fi

I'm sure you do not have problem because pburn is also installed in your official Debian Wheezy.
Pburn has included link /usr/bin/gtkdialog4
Menumaker searches for gtkdialog4 (which after installing pburn is link to /usr/bin/gtkdialog). gtkdialog4 is missing when pburn is not installed and menumaker searches for gtkdialog3 (but /usr/bin/gtkdialog3 is different version from /usr/bin/gtkdialog instead link to gtkdialog) and does not start.

Solved by:
Removing /usr/bin/gtkdialog4 from pburn package.
Adding /usr/bin/gtkdialog4 to gtkdialog package.
Both uploaded in testing repository.

I'm not sure this is the best way to fix it. Maybe we need to separate gtkdialog versions /usr/bin/gtkdialog and /usr/bin/gtkdialog3 in different packages depending what version is gtkdialog. And then adding the correct gtkdialog version as dependency.
Or easier fix will be just to edit menumaker to use /usr/bin/gtkdialog and keep in mind checking for the same problem in other scripts.

FFconvert works with fresh installed standard Debian. The problem was something I did while testing I guess.

Toni

[fredx181]

Hi Toni,

Logout and login and I can shutdown, reboot, save2flash without password prompt.
It will work also for any older DD version. Nice Smile

I'm sure you do not have problem because pburn is also installed in your official Debian Wheezy.
Pburn has included link /usr/bin/gtkdialog4

Nice find, Toni!, glad it's solved.
Indeed I have pburn installed on my official install.

Here's script with yad dialogs for activate/deactivate required password for shutdown/reboot.
It 'toggles' activate and deactivate, depending if the user is member of group wheel or not.
Tell me if you like something changed for it.
I'll leave the menu entry name up to you, something like: Activate/Deactivate-shutdown-password-required maybe?
Attached: shutdown-pass-activate_deactivate.tar.gz

Edit: Made small mistake, re-uploaded fixed version.

Fred

[saintless]

I'll leave the menu entry name up to you, something like: Activate/Deactivate-shutdown-password-required maybe?
Attached: shutdown-pass-activate_deactivate.tar.gz

Thanks, Fred, looks much better this way
I will put the script in /opt/bin. lets keep /opt/bin for scripts available only in DD without making deb packages for them (if you do not mind). And for all new made (and not included yet) deb packages start using /usr/local/bin instead /opt/bin.
I think Activate/Deactivate Shutdown Password is good name.

I will add menu entry as line for IceWM /home/puppy/.icewm/menu and /etc/skel/.icewm/menu and for Jwm in /home/puppy/.jwm/jwm.head and /etc/skel/.jwm/jwm.head
I tried to use local desktop and menu files for user account only but seems Jwm does not read ~/.menu content for local user files. I thought it is caused by menu-puppy from Terry somehow but no. After deleting all files for menu-puppy, restoring the link to point /usr/bin/update-menus and installing official Jwm deb package update-menus command also does not read files in ~/.menu.
IceWM does it without problem and adds to the menu what is available in ~/.menu.
Strange issue that needs investigation some day.
I also forgot about IceWM in the instruction post. It needs adding sudo in /home/puppy/.icewm/preferences:

Code: Select all

#  Command to shutdown the system
ShutdownCommand="sudo /sbin/poweroff"

#  Command to reboot the system
RebootCommand="sudo /sbin/reboot"

Toni

[fredx181]

Hi Toni,

I will add menu entry as line for IceWM /home/puppy/.icewm/menu and /etc/skel/.icewm/menu and for Jwm in /home/puppy/.jwm/jwm.head and /etc/skel/.jwm/jwm.head
I tried to use local desktop and menu files for user account only but seems Jwm does not read ~/.menu content for local user files. I thought it is caused by menu-puppy from Terry somehow but no.
.....
.....

I didn't realize adding a menu entry for specific user would be so complicated.
Just tried on Jwm version if placing a .desktop file in ~/.local/share/applications and do "update-menus" would work, but it seems not.
On OpenBox version this works.
Looks like you figured all out already but just for info: the script gives message and exits when logged in as root.
So the .desktop file could as well be in /usr/share/applications, then doing "update-menus" should add it to menu.

Fred

[saintless]

Hi, Fred.

Just tried on Jwm version if placing a .desktop file in ~/.local/share/applications and do "update-menus" would work, but it seems not.
On OpenBox version this works.

Terry's mk-jwm.menu (menu-puppy) does not support ~/.local/share/applications as path if I do not mistake. I have this in mind and possible alternative menu script that works with any available path for .desktop files.
But the problem is actually the standard debian update-menus method does not work with Jwm after restoring with System -> Menu Debian.
Adding menu file in /home/puppy/.menu the menu entry appears in IceWM but not in Jwm. Seems like update-menus does not work well with Jwm.

Small issue with shutdown-pass-activate_deactivate:
If I click cancel on gsu window it gives message the user is added to group wheel but it is not actually added.

Toni

[fredx181]

Small issue with shutdown-pass-activate_deactivate:
If I click cancel on gsu window it gives message the user is added to group wheel but it is not actually added.

Yes, that needs to be fixed, Thanks!
Forgot to set $ret variable (ret=$?) after commands.
Attached fixed: shutdown-pass-activate_deactivate.tar.gz

Fred

[saintless]

Thanks, Fred!

I will change the link in next version changes post to point the new file.
Just for information I'm experimenting with mjwm menu and I think I will include it as third menu method in Jwm version. It reads ~/.local/share/applications or any other paths scanning for desktop files. In combinantion with Terry's mk-jwm.menu I can make it auto-update the programs after installing/removing new packages.
Then I will continue modding DD packages for the testing repository.

Toni

[fredx181]

Hi Toni,

Just for information I'm experimenting with mjwm menu and I think I will include it as third menu method in Jwm version.

Looks promising!
It's a pity that Terry is not around these days to possibly support or upgrade his applications.
If I remember well you wrote sometime ago to send PM to him, you got no reply?

Fred

[saintless]

Hi, Fred.

I got reply from Terry, but he was too busy with personal problems. I'm sure he will write when he has time to help.

I like mjwm a lot. It will be included with sure as System -> Menu-MJWM option. Need some more testing and exploring how to get icons for categories and some other things.

Edit: Using puppy.mjwm default configuration looks better, but will be nice if Others category has icon also.

[saintless]

Forgot to set $ret variable (ret=$?) after commands.
Attached fixed: shutdown-pass-activate_deactivate.tar.gz

Hi, Fred.

Can you check this new file. I think it is the same as the old one and has the same issue.

Edit: To explain better here is what happens on Jwm version after installing latest gsu and starting shutdown-pass-activate_deactivate as user puppy:
First run I use Cancel button on gsu window and get this message on the attached picture: "Puppy user added to group wheel." But it is not added:

Code: Select all

puppy@debian:~$ id -nG puppy
puppy cdrom sudo audio video fuse

Second run I chose to add it and confirm typing the password in gsu window. All is fine and puppy is added to group wheel:

Code: Select all

puppy@debian:~$ id -nG puppy
puppy cdrom sudo audio video fuse wheel

From this point every time I use shutdown-pass-activate_deactivate I do not get anymore gsu window and puppy is added/removed without showing up gsu window anymore. Note this happens even if I do not logout and login and the changes from adding puppy to group wheel should not be activated yet. But logout and login does not change the missing gsu window. I think it has to show gsu window every time running shutdown-pass-activate_deactivate. Even when puppy is already added to group wheel. This is the content of /etc/sudoers:

Code: Select all

#
# 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="/opt/bin:/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
%wheel ALL= NOPASSWD: /sbin/shutdown, /sbin/reboot, /sbin/poweroff, /usr/bin/wmpoweroff, /usr/bin/wmreboot, /usr/bin/save2flash

# See sudoers(5) for more information on "#include" directives:

#includedir /etc/sudoers.d

Edit2: Changing latest gsu to gsu-xterm makes gsu window to show up as it should each time running shutdown-pass-activate_deactivate.
The problems I see at this moment:

1. shutdown-pass-activate_deactivate should not give false message on first run "puppy is added to group wheel" when it is not actually added.
2. Latest gsu-yad does not act as gsu-xterm and makes possible to run commands with gsu line without password confirmation (atleast for shutdown password activate/deactivate). It should not skip the password prompt if the exact NOPASSWD command is not added in wheel line in /etc/sudoers and user added to group wheel, logout and login back.

Edit3: I guess "sudo -S" in gsu is the reason gsu does not show up second time but I'm not sure yet. If it is so, Fred, I do not like this as default gsu setup for Jwm version. I prefer prompt for password each time when gsu is called. NOPASSWD should be set only from /etc/sudoers. I will test it more when I get mjwm working right. Maybe it is not something in gsu but other reason.

Toni

[fredx181]

Hi Toni,

The problems I see at this moment:

1. shutdown-pass-activate_deactivate should not give false message on first run "puppy is added to group wheel" when it is not actually added.
2. Latest gsu-yad does not act as gsu-xterm and makes possible to run commands with gsu line without password confirmation (atleast for shutdown password activate/deactivate). It should not skip the password prompt if the exact NOPASSWD command is not added in wheel line in /etc/sudoers and user added to group wheel, logout and login back.

1. I cannot reproduce this at the moment, does this happen for you after rebooting also?
Btw, how you define "logout and login back in" ? Exit X and startx doesn't do that, I think.
2. This is complicated stuff, there's also the default timeout for giving password for sudo (from what I read it is 5 minutes). I don't think that the gsu script includes some hack to avoid entering password (so that's why I guess it has to do with some default behaviour of sudo, I'm still testing to find out what and how)
Also this I found when running for example apt2sfs:

Code: Select all

puppy@dog:/$ sudo apt2sfs
[sudo] password for puppy: 
puppy@dog:/$ sudo apt2sfs
puppy@dog:/$ 

When running from same terminal second time it doesn't ask for password.
Then when opening new terminal and run "sudo apt2sfs" again password is required.
Then when running from menu it doesn't ask for password.

Edit: correction: when running second time from menu it doesn't ask for password.

Maybe removing this section from /opt/bin/gsu makes it behave like xterm-gsu:

Code: Select all

    # check for sudo
    sudo_check=$(sudo -H -S -- echo SUDO_OK 2>&1 &)
    if [[ $sudo_check == "SUDO_OK" ]]; then
        exec_command=$(eval sudo $cmd 2>&1 &)
OUTPUT=$(echo $exec_command | grep -o "command not found")

if [ "$OUTPUT" = "command not found" ]; then
yad --text="    Sorry, could not find command:     \n    '$cmd' .  \n     Please try again. " --button="gtk-close:0"
fi
        exit $?
    fi

But as I said still needs testing and honestly I'm confused about how these things work.
Maybe the thing to test after we possibly give up yad-gsu is ktsuss-sudo and if that gives problems also, we better use the xterm-gsu.
I think the xterm-gsu asks for password every time because new terminal is executed.

Maybe you did already but I'll test also how gksu behaves with timeout etc..

Edit:

1. I cannot reproduce this at the moment, does this happen for you after rebooting also?

Can reproduce it now, can't figure out why yet, I'll look at it.

Fred