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

[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

[saintless]

Hi, Fred.
Take your time. I just share what I see as potential problems from testing.

Btw, how you define "logout and login back in" ? Exit X and startx doesn't do that, I think.

With XDM activated even Ctrl+Alt+BackSpase drops out to login prompt.
Without XDM -> Shutdown -> Exit WM:

Code: Select all

exit
login
puppy
puppy
startx

...honestly I'm confused about how these things work.

Me too, Fred, I will do more testing with sudo and gksu and gsu. I remeber I had troubles with permissions in Jwm version with ktsuss-gsu but I will test it again.

Standard Debian Gnome asks for password only first time starting gksu if I do not mistake. Then it does not ask for password anymore.
I know in the same terminal sudo does not ask for password second time. This why I wrote it might be not gsu problem.
Still I do not like surprises like removing by accident user from group wheel just because for some reason password prompt is not active. Atleast I like to know why this happens.
We have much work to do for the next version, but lets keep it for later - after New Year.

Toni

[fredx181]

Hi Toni,

Take your time. I just share what I see as potential problems from testing.

Yes, and thanks for testing.
I see it as my responsibility because I like to include the graphical sudo

Still I do not like surprises like removing by accident user from group wheel just because for some reason password prompt is not active. Atleast I like to know why this happens.

I assume you refer to this you wrote earlier:

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:

I found the reason for it is mistake in gsu script, on line 28 instead of:

Code: Select all

[[ $ret -ne 0 ]] && exit 0

It should be:

Code: Select all

[[ $ret -ne 0 ]] && exit 1

The shutdown-pass-activate_deactivate script gets $ret value from it, that's why it gives message 'succeeded' (exit 0), when canceled it should read $ret value as 1 (exit 1)

Attached new gsu with correction and:
"gsu-notimeout" from which I deleted the "check for sudo" part and also added "sudo -K" command (it should disable timeout for password, so this way every time entering password is required).
I see the "timeout" for password as a feature which is enabled by default for some time (still don't know how long, I read different things about it on documentation on the net, if it's 5 minutes or 15 minutes, didn't yet have the patience to test )
Or maybe it is valid for the whole login session.

Fred

[saintless]

Thanks, Fred

I confirm it is working and I vote for gsu-notimeout as default.
We can include both in gsu package if you like:
gsu (renamed from gsu-notimeout)
gsu-timeout (or other name for the other gsu).
Then the user can easy switch the names in /opt/bin if needed without having troubles to uninstall/reinstall gsu package later.

From what I read gksu, gsudo, ktsuss should be used inside /usr/share/application desktop files or /usr/share/menu if the user decides to run applications as root or to skip typing sudo in terminal for programs in /sbin, /usr/sbin. And I think most of the posts describe this as not recommended.

I think the packages in debian repository are made by default for multiuser use and the solution they use is not sudo or gksu, but the program write only in $HOME/ and it is started from PATH available as default for user account (like /usr/bin, /usre/local/bin, /bin).

In DebianDog we use different method from the start adding gsu line for almost every script.
William for example makes the packages work without gsu line (ffconvert, precord, pavrecord, domyfile, domycommand).
I don't say to skip gsu line inside scripts in the future, but we can hope the user will use them careful after having password prompt every time starting the program.
For example latest apt2sfs can easy break the system without reading how to use it properly. If I cancel the proces installing packages in the middle or after, I have few seconds interval before the message "Trying to recover dpkg databse" appears. I can easy reboot or logout for these few seconds or just to ignore the message and reboot. Or maybe pawer failure could happen. Then status file is broken.
The first apt2sfs without installing packages or the later (without copying status from main module) were not smart, but safe.
All I mean is we should have password prompt every time gsu script is called hoping this will make the user more careful with scripts containing gsu line.

I hope this makes sense

BTW just for information we have available different GUI with root password prompt (su-to-root -X -c command-name). For example Gparted /usr/share/menu file is started this way by default:

Code: Select all

?package(gparted):\
	needs="X11"\
	section="Applications/System/Administration"\
	title="GNOME partition editor"\
	command="su-to-root -X -c /usr/sbin/gparted"\
	icon="/usr/share/pixmaps/gparted.xpm"

Picture attached.

Happy Holidays!

[fredx181]

Hi Toni,

We can include both in gsu package if you like:
gsu (renamed from gsu-notimeout)
gsu-timeout (or other name for the other gsu).
Then the user can easy switch the names in /opt/bin if needed without having troubles to uninstall/reinstall gsu package later.

Yes, it's fine by me this way.

.....
.....
I hope this makes sense Smile

It surely does.

BTW just for information we have available different GUI with root password prompt (su-to-root -X -c command-name). For example Gparted /usr/share/menu file is started this way by default:

The GUI you see is just the same as ktsuss.
The su-to-root script checks for 'which ktsuss' and use it if any other (like gksu or kdesu) is not available

Happy Holidays!

Thanks, same to you Toni!

[fredx181]

Hi All,

Here's a script using yad that does a similar thing as gtkdialog-splash. (It's much more simple though)
.
Started this to make it possible to show a nicer colored splash message in scripts that use yad as frontend.
(don't like mixing it with gtkdialog-splash)
All yad parameters can be used plus a few additions (foreground, background, fontname)
For usage type: yad-splash --help

Some examples: (see also pictures)
Example1:

Code: Select all

./yad-splash --image browser-dload --image-on-top --bg '#F4E48F' --text "  Downloading...  " --undecorated --no-buttons &

Example2:

Code: Select all

./yad-splash --borders 5  --text "    Virus detected! \n Name is: Window$  \n \n    Remove it?" --fontname "Bold 18" --bg "dark red" --fg "yellow" --undecorated --button="gtk-yes:0" &

Attached: yad-splash.tar.gz

Edit: To show what's more possible here's another example (more complicated, using <span ...>)
Example3:

Code: Select all

./yad-splash --borders 5  --text "<span size='large' foreground='#432424'><b> All updates are done.  </b></span> \n <span foreground='dark red'><b> A reboot is required. \n      Reboot now?  </b></span>" --bg '#F4E48F' --fg '#7B2365' --undecorated &

This makes the buttons font different color as the text.

Fred

[saintless]

Hi, Fred.

Here's a script using yad that does a similar thing as gtkdialog-splash. (It's much more simple though)

Added in next version changes post. I guess you are going to use it for yad scripts in the future.
If you like to have new scripts containing yad-splash compatible with different Debian I can make deb package (location /usr/local/bin/yad-splash) and add yad as dependency inside control.

Some changes in the testing repository:

Terry's mk-jwm.menu added as mkjwmmenu_1.0.0-1_i386.deb containing Menu-Puppy and Menu-Debian setup.
MJWM added as /mjwm_4.0.0-1_i386.deb with dependency mkjwmmenu (because it will use auto-update menus scripts from there).
Both packages work with standard Debian if JWM is started. Menu-Debian and Menu-MJWM work with dash. Only Menu-Puppy (mk-jwm.menu) needs bash reconfiguration.

Added extra category in some packages desktop file to make them appear in the right place for menu-MJWM.

x11-xserver-utils and xdm packages - dependency cpp was removed from both. I don't like to keep it removed since we are making DebianDog packages compatible with standard Debian. Now cpp is added as Recommends: in control and will not be installed in DebianDog. But cpp will be installed in standard Debian where recommended packages are auto-installed. This means if both packages are upgraded in standard Debian cpp will be kept as it should without creating troubles.

RemasterCow with .wh support needs a button or other way to provide information explaining properly what whitout function means and how to use it properly (only with enabled dpkg registration).

We need to decide what to do with (15. export LC_ALL=C) from next version changes post. Just post with information about this problem or to add it in all scripts in the future?

But all this can wait till next year

Edit: BTW found one situation when apt2sfs will fail creating broken module. Using with save file if there is no space left the instalation process fails (reading the messages in terminal), but apt2sfs continue with copying in work folder, uninstalling packages and creating new module. This may happen often for someone using small save file like me (300 - 1000Mb).
I think dpkg checks if there is enough free space only for downloading the packages and not if there is enough space to extract them after that.
Maybe we can add this information in apt2sfs window with bold or red text?

Toni

[fredx181]

Hi Toni,

Added in next version changes post. I guess you are going to use it for yad scripts in the future.
If you like to have new scripts containing yad-splash compatible with different Debian I can make deb package (location /usr/local/bin/yad-splash) and add yad as dependency inside control.

Yes, that would be good, it may be useful sometimes for new scripts.

Some changes in the testing repository:
....
....

Seems like you made improvement!

RemasterCow with .wh support needs a button or other way to provide information explaining properly what whitout function means and how to use it properly (only with enabled dpkg registration).

Ok, I recently found out that yad supports also a "normal" button (instead of the sort of hidden button used in Remastercow for showing info about dpkg registration)

Two ways:
Create file with the info inside (and make it read-only), then it could be like this with added "Information" button to Remastercow:
(as example used /opt/docs/welcome using leafpad, can be changed maybe to 'default_editor')

Code: Select all

yad --title "Info-button-example" --borders 5 --text "Example for button opening text file for info" --button "gtk-info:leafpad /opt/docs/welcome" --button "gtk-quit:1" --button "gtk-ok:0"

Or like this using yad text-info

Code: Select all

yad --title "Info-button-example" --borders 5 --text "Example for button showing info." --button "gtk-info:sh -c "'"'"echo -e 'Information... \nMore information on new line. \nEven more information on new line' | yad --title "Information" --margins 5 --text-info --width 500 --height 400 --wrap"'"'"" --button "gtk-cancel:1" --button "gtk-ok:0"

You choose!
If you prefer the latter you could pass me the text (next year ) and I'll add it to the script.
Same thing for apt2sfs maybe?

Edit:

We need to decide what to do with (15. export LC_ALL=C) from next version changes post. Just post with information about this problem or to add it in all scripts in the future?

Not add it to all scripts in the future, only when needed.
It's only a problem for some scripts, specially the ones with some grep commandline that checks for output text (which isn't always english when locale has been changed)
I will test more scripts for any issues.

Fred

[saintless]

Thanks, Fred!
I will test both button options but for RemasterCow I think it is best to have the same as for dpkg registration.
Button with title "Information" could be easy ignored. I'm testing button just below whiteout check box with title "Click here for more info about whiteout files". I will upload it after the holidays for final check and decision from you.

About apt2sfs I need some more time to test how dpkg checks for free space before installing packages. It is more likely the checking is for free space to extract the packages but it doesn't calculate inside the space needed for downloaded deb files.
The latest apt2sfs has disadvantage in such situation compared to the older apt2sfs. Even if the user can see the error messages for not enough space in terminal window we need to make sure apt2sfs will not be closed without restoring status file. The information must be visible on first run at least and well explained. Maybe we can use first time run message that apt2sfs already has to recommend clicking the "Information" button before using the program. We will discuss this when I have something for testing.

Merry Christmas!

[fredx181]

Hi Toni,

About apt2sfs I need some more time to test how dpkg checks for free space before installing packages. It is more likely the checking is for free space to extract the packages but it doesn't calculate inside the space needed for downloaded deb files.
The latest apt2sfs has disadvantage in such situation compared to the older apt2sfs. Even if the user can see the error messages for not enough space in terminal window we need to make sure apt2sfs will not be closed without restoring status file. The information must be visible on first run at least and well explained. Maybe we can use first time run message that apt2sfs already has to recommend clicking the "Information" button before using the program. We will discuss this when I have something for testing.

Thanks for noticing this issue with apt2sfs.
I decided the best to do is improve error checking for apt2sfs.
I think one of the most important things for a script is error checking (and btw, one of the most difficult things) so that the user isn't confronted with any surprises.

It checks now for any dpkg error (on line 388-397 that depends on added lines 336-339) and if there is, it shows clear message with last log lines in bold (from /tmp/aptout) and in red font a message informing about "No space left on device" and the possible reason (to small savefile or not enough RAM)
In this error case the module will not be created and the system will be restored.
(I think no info button will be needed this way)

Test it whenever you like, no hurry at all.

Attached new apt2sfs.tar.gz (finished it just before Christmas )

Btw, for me Christmas doesn't mean much to me (I'm not religious), I have dinner appointment tomorrow and that's it, live goes on as usual except that around me some things are stopped, so I'm sort of forced to have holiday, which is Ok .

Fred

[saintless]

Much better this way, Fred, thank you!



In next version changes post apt2sfs linked to this new version.

Edit: And testing RemasterCow with whiteout files info button. Still not sure if it is clearly explained.

Edit2: Fred, for next update remove /opt/bin/cow-nosave, cow-save-part, cow-save-file. I will add it to the changes post. After we use as default your cowsave the old scripts could become dangerous if started by accident. They depend on the boot method to work properly.

Edit3: Flashplayerchoice does not work for me with yad-gsu (timeout or notimeout), Fred. Tested only as user in Jwm version but I think it will be good to include gsu-xterm in gsu.deb and use it in such situations. I will test later how to fix flashplayerchoice or the menu files to work with yad-gsu. We will need much testing before next update.

Edit4: Same with Change frisbee with sns script. Doesn't work with gsu-yad. I can include gsu-xterm in gsu-deb and change the lines for scripts with this problem to gsu-xterm. But this will break the same scripts after installing the gsu.deb on older DD version. This gsu change gets too complicated and I'm sure I will miss something that does not work after changing gsu-xterm in Jwm version.
What do you think, Fred? Any idea how to keep compatibility with old DD versions and using gsu-yad. I don't like the idea to edit the scripts for yad-gsu because for older DD versions will need reinstalling/replacing all moded to work with gsu-yad scripts after installing gsu.deb. And installing new gsu.deb will be needed to make shutdown without password work on old DD. I think the safe way is to include in gsu.deb gsu-xterm as default /opt/bin/gsu.

Toni