Run Puppy as fido - urxvt dies not work

[rb4linux]

Hello:

I'm using Slacko32 6.3.0 (nice piece of work).

By commenting out the --autologin root from /etc/inittab I have managed to login as fido and start JWM. Just 1 problem, unable to start urxvt. When I click on the console button on the desktop or from the lower-left menu (Utility) entry, nothing happens.
Cannot start it by clicking on item from ROX-Filer either

I was able to download/install the xfce-terminal app (runs as root not fido)

All other apps seem to work fine.

If I cannot start some type of xterm/console then what is the point?

Have already tried to add /usr/bin/urxvt to /etc/sudoers.
Have tried copy of /root to /home/fido

I do not wish to go down the years-old discussion(s) of surfing as root as being safe enough. Just accept that I would like to work as fido (or some other user other than root).

Any suggestions would be greatly appreciated and I will share any solutions with all.

I have noticed that the xwin file writes many files to /tmp.
The error messages from /tmp/xerrs.log didn't seem to be too helpful.

Thanks

[bigpup]

From /usr/share/doc/root.htm

Fido is another name for a dog, and is a full non-root login account, as you would get in any other Linux distro. With one peculiarity, it's home directory is /root (which may indeed seem very peculiar to you, but there is a reason for it!). As with other distros, you would use 'su' or 'sudo' to perform administrator activities.

fido always requires administrator password to perform administrator-level operations.

fido is offered as an option at the first shutdown of Puppy, when you are creating a save-file for the session. If you opt for fido, at next bootup you will be automatically logged in as fido. Note though, fido is not quite mature, so not yet recommended to be used.

[unicorn316386]

Created a new savefile as user fido:
- Menu -> Exit -> Exit to Prompt works for command line
- New Firewall would not run (needs admin privileges?)
- Using "pmedia=ataflash", pressing the Save icon has "waiting to save" indefinitely

Think I will stick to root for simplicity fun experiment nonetheless.

[rb4linux]

@unicorn316386

Thanks for you reply.

Previously I tied using a save file for fido and it worked ok but I could still not launch urxvt under JWM as fido.

Noticed that sudo was missing (from Slacko32 6.3.0) so that fido could not restart or shutdown computer. Downloaded the compiler package and sudo 1.8.*.tgz, compiled, installed and now reboot/shutdown work with fido as expected (on my computer).

Modified the /etc/sudoers file to append /usr/bin/urxvt for %users (and fido is a member of the users group) but could still not get urxvt to work under JWM. Perhaps there is something obvious that I am missing?

I will keep trying. Any suggestions from yourself or anyone else on how to resolve this problem would be greatly appreciated.

I think users fido & spot are great ideas and it would be very nice to finally get fido to work as originally intended.

Thanks again


PS "urxvt dies" contains a typo but seems somewhat more descriptive (LOL)

[BarryK]

Hi,
Yeah, it would be nice if you guys could fix the unresolved issues with fido.

I created fido sometime ago... let's see, about middle of 2013. haven't done anything with it since then.

You do not have to manually edit /etc/inittab, seup, to change between running as fido and root, is taken care of by a script, /usr/sbin/loginmanager, in the System menu as "Login and Security Manager"
-- though, I can't say whether Slacko still adheres to this.

Yes, you need sudo. 32-bit and 64-bit pets are available:
32-bit: http://distro.ibiblio.org/quirky/quirky ... 1.8.10.pet
64-bit: http://distro.ibiblio.org/quirky/quirky ... pril64.pet

...someone tell Mick to put in the next build of Slacko.

There is are files /etc/sudoers and /etc/sudo.conf in Woof, not in the pet, so you will have it in your final Puppy build. At least was in Woof2, presumably still in woofCE.

I posted about fido in my blog, looking back in 2013:
http://bkhome.org/blog2/?viewDetailed=00278
http://bkhome.org/blog2/?viewDetailed=00269
http://bkhome.org/blog2/?viewDetailed=00237

[rb4linux]

Hello:

Thanks for your response.

Did some more hacking: (try the following if interested)
start x as root, drop to command prompt, logout, login as fido, type xinit (to start x), click console button on desktop then exit to prompt.

The following message can be found on the screen (or text file if you redirected xinit output there)

urxvt can't initialize pseudo-tty, aborting

I had a look at /dev/*ty* and just about all files have 755 permission (looks no different than most linux distributions).
sudo had been added to the system.

If anyone has an idea on how to resolve this issue then perhaps fido could be one step closer to working as expected.

I noticed a few things after looking at /usr/bin/xwin in greater detail.
There seems to be a heavy emphasis on hard-coding /root/ and /tmp/ throughout the file as well as writing to files in /etc. If someone was looking for a small system to run in memory but wanted logins for say 2 adults and 3 kids then hard-coding to /root might be a challenge if everyone wanted different desktops.

Not knowing much of the history as to why certain things were done a certain way makes it is difficult to suggest blanket changes (one line could break the entire system).

How do developers feel about making the system more flexible so that multiple users are easier to implement in the future? Any changes must not break anything in the current system.
Just by looking at the xwin script, I suspect that the task could become fairly involved. Might take a separate prototype project at least until things could be stabilized.

However, such changes might help broaden the interest in puppy.


For now I'd be happy if the urxvt issue could be resolved.

BTW using a save file did not resolve the urxvt issue (otherwise I would just have taken that direction). Please let me know if there is a bug in the save file feature.

Thanks for any suggestions

[dancytron]

You might want to try one of the Debian Dog distributions.

They auto login as root, but all the stuff for multiple users is still there and can be used. They are more or less Debian live made to look and act Puppyish.

http://murga-linux.com/puppy/viewtopic.php?t=99460

https://github.com/DebianDog/Jessie/

[jamesbond]

Hello:

Thanks for your response.

Did some more hacking: (try the following if interested)
start x as root, drop to command prompt, logout, login as fido, type xinit (to start x), click console button on desktop then exit to prompt.

The following message can be found on the screen (or text file if you redirected xinit output there)

urxvt can't initialize pseudo-tty, aborting

I had a look at /dev/*ty* and just about all files have 755 permission (looks no different than most linux distributions).
sudo had been added to the system.

If anyone has an idea on how to resolve this issue then perhaps fido could be one step closer to working as expected.

Edit /etc/group (while as root) and make sure the line that starts with "tty" looks like this:

Code: Select all

tty:x:2:fido

Login as fido and launch urxvt. If not working try rebooting first.

I noticed a few things after looking at /usr/bin/xwin in greater detail.
There seems to be a heavy emphasis on hard-coding /root/ and /tmp/ throughout the file as well as writing to files in /etc. If someone was looking for a small system to run in memory but wanted logins for say 2 adults and 3 kids then hard-coding to /root might be a challenge if everyone wanted different desktops.

Puppy's way is to use different savefile for different person. Change user and you need to reboot and use a different savefile.

[rb4linux]

@JamesBond

Thanks, yes I tried that. in fact the /etc/group file had two entries for tty (I removed the first one and kept the one with root,spot.fido).

Reboot did not seem to help.

Was going to try a Tahr version of puppy.

Still working on the issue.

[rb4linux]

@dancytron

Thanks for the links.

I tried the DebianDog xfce and JWM iso files loaded into a VM. Looks more like Porteus than puppy. The image files look like puppy sfs files but the setup looks like Porteus. I prefer the Porteus module setup.

Last I read Porteus was heading towards Arch (wait and see).

I was looking for a Debian version of Porteus.

At first glance DebianDog doesn't look as polished as Porteus but I need to spend more time with it.

I wonder if the Porteus team knows about DebianDog?

I think it is a good idea to look at other distributions as there are so many good ideas out there.

Thanks again

[rb4linux]

@dancytron

Just tried the following with DebianDog (JWM iso).

Default boot into X as root (from iso file)
logout/dropout to command line
(as root) su puppy
startx (to start x windows as puppy).
Now the user is free to surf as puppy (not root).

Instead of su puppy could have just as easily created a new user first.

It would be cool if Puppy Linux could work that easy.

Thanks again

[dancytron]

You're welcome.

TBH, I just use it as root.

Look in the How To thread, there is a way to turn on the login manager so that you can choose the user you want to log in as at the beginning.

The SFS builder is a great feature that Puppy should try to reproduce.

It isn't as newbie proof as Puppy, but Debian Dog has a lot going for it (but no marketing whatsoever).

[Karl Godt]

When rxvt has no pseudo tty, it wants them in /dev/pts/ directory ,

not as /dev/tty* .

It is the mountpoint /dev/pts that needs to be a mountpoint for the devpts filesystem .

And the /dev/pts/[0-9]* device files are automatically made by triggering

/dev/ptmx device .

Maybe /dev/pts/ptmx is searched for too .

My /dev/ptmx permissions as root :

Code: Select all

# ls -l /dev/ptmx
crw-rw-rw- 1 root root 5, 2 2015-12-22 04:15 /dev/ptmx
# ls -l /dev/pts/ptmx
c--------- 1 root root 5, 2 2015-12-21 22:26 /dev/pts/ptmx

and this as testuser2 :

Code: Select all

# adduser testuser2 -h /home/testuser -G nobody  -u 2889
Changing password for testuser2
New password: 
Bad password: too weak
Retype password: 
Password for testuser2 changed by root
# login testuser2
Password: 

# rxvt
# ls -l /dev/pts
total 0
crw------- 1 testuser2 nobody 136, 0 2015-12-22 04:21 0
crw--w---- 1 root      tty    136, 1 2015-12-22 04:18 1
crw--w---- 1 root      tty    136, 2 2015-12-22 04:17 2
c--------- 1 root      root     5, 2 2015-12-21 22:26 ptmx
# ls -l /dev/ptmx
crw-rw-rw- 1 root root 5, 2 2015-12-22 04:21 /dev/ptmx
# 

rxvt and urxvt work for me started from a normal root console
after logged in as testuser2 ( lupu 511 ) .

[rb4linux]

Karl Godt

Thanks for the ideas.

Staying with the ubuntu theme for puppy, I checked Puppy 5.4 (precise) and I could reproduce your results. Now trying again with Puppy 6.0 (Tahr) I could not open rxvt or urxvt. I didn't notice much change in the /dev file permissions between the two different releases.

Puppy 6.0 /dev/ptmx (minor difference)
crw-rw---- ... /dev/ptmx

Tried chmod 666 /dev/ptmx and then su -l newuser but could not launch urxvt.

Perhaps something changed between builds (over a two-year period). Puppy 6.0 came out in late 2014 I think.

I am not sure at this point if some type of bug was inadvertently introduced into the system. Needs more investigation.

Thanks

[rb4linux]

I found a possible work-around at

https://bbs.archlinux.org/viewtopic.php ... 8#p1313998

Removed the /dev/pts entry from /etc/fstab and then manually typed (in root console)

Code: Select all

mount -t devpts -o rw,nosuid,noexec,gid=2,mode=620,ptmxmode=000 devpts /dev/pts

It works, not sure why as I tried many different variations of putting the same info into the /etc/fstab file.

Now I could modify the /etc/rc.d/rc.sysinit fle to include the above mount after the mount -a line (and removing the entry from fstab).

Still not really sure what is going on but a solution using /etc/fstab only is much cleaner than hacking /etc/rc.d/rc.sysinit
There should be a more elegant solution.

More research is required.

[rb4linux]

Just a quick update, in case anyone was following along.

Puppy Slacko non-PAE (32-bit) 6.3.0

After more research I have come up with a simpler work around.
After JWM starts, open an urxvt window and type the following two lines (both are required)

[or for anyone wishing to customize a CD or sfs file, put the lines into a short script file in /etc/rc.d or maybe /usr/local/bin and append a line to /etc/rc.d/rc.local to execute the script file]

Code: Select all

chmod 755 /dev/pts
chgrp tty /dev/ptmx

Now the following commands

Code: Select all

su fido
(as fido) urxvt

will permit user fido to open an urxvt window on the desktop.

The idea was inspired from a previous reply in this thread (Karl Godt) and then looking in more detail at the files on Puppy Slacko (32-bit) 5.7.0

Since messing around with mount options is not really required, I didn't want anyone to go down that road (even though some people will find the details interesting).

If you look at /etc/rc.d/rc.sysinit (starting around line 360) it may eventually become clear why not mounting /dev/pts during boot-up and mounting it later represents a work-around for this problem.

I will add more details in a later post.

Currently I am unsure of the security implications of adding those two lines so I advise people to take care and do more research.

I have not done extensive testing and do not know if the modifications will break anything else.

Now I can boot to JWM (as root), drop down to the command line, su fido and start JWM and then launch an urxvt window. More changes are required to actually surf as fido.

What is presented here is another work-around and not really a solution. A solution implies a permanent fix.

Thanks

[Karl Godt]

Nice observation rb4linux !

current rc.sysinit should have these lines:

Code: Select all

mkdir -p /dev/pts #120503 if kernel mounts a f.s. on /dev, removes my skeleton /dev
busybox mount /dev/pts ;STATUS=$((STATUS+$?))
mkdir /sys 2>/dev/null
busybox mount -t sysfs none /sys ;STATUS=$((STATUS+$?))

Since /sys has also an entry in /etc/fstab,
it could be also simply mounted as /dev/pts:

Code: Select all

busybox mount /sys;STATUS=$((STATUS+$?))

OR /dev/pts could be mounted as the /sys line,
as the mountline of your previous post showed.

BUT: Some scripts call /sbin/probepart and /bin/mount
and filter out entries with "none" entries.

IF you use devtps as "device" entry in fstab or mount line, make sure the other scripts filter "devpts" .
OR use "none" instead "devpts" :

Code: Select all

none          /dev/pts     devpts   rw,nosuid,noexec,gid=2,mode=620,ptmxmode=000 0 0

Code: Select all

mount -t devpts -o rw,nosuid,noexec,gid=2,mode=620,ptmxmode=000 0 0 none /dev/pts

I have made the fstab entry now for my current installation ( Puppy 4 times ) and need to reboot to check if that works.

[rb4linux]

Hello:

The following is a snippet from a script file I am preparing

Code: Select all

# Puppy Slacko32 6.3.0 and Puppy Tahr32 6.0.5 ship with 
# Ownership/permissions 
# /dev/pts          /dev/ptmx
# root.root 660  root.root 660

# The following two commands are required so that a non-root user
# like fido can open urxvt windows in JWM

chmod 755 /dev/pts 2>/dev/null
chgrp tty /dev/ptmx

# A comparison of the ownership and permission of these 
# two items might help determine if the above commands are
# consistent.

# Distribution                 Ownership and permissions    
#                              /dev/pts       /dev/ptmx

# DebianDog(32) Jesse-JWM      root.root 755  root.tty 666
# Fedora(64) 23.0              root.root 755  root.tty 666
# LinuxMint(64) 17.3           root.root 755  root.tty 666
# Porteus(32) 3.1              root.root 755  root.tty 666
# Ubuntu(64 LiveDVD) 14.04.1   root.root 755  root.tty 666

# The above commands seem to be consistent with other distributions.

The two suggested commands might represent the easiest work-around as remastering a new CD/iso would not be required.

The Code box is a bit messy but looks right in a fixed-font text editor.

Thanks to all who provided constructive comments.