EasyOS version 2.3.2, June 22, 2020

[BarryK]

To scsijon,

"Rodney, I had the same problem when capturing from my browser until I put the browser into full screen (maximize) mode,
it apparently doesn't like to capture partially complete screens,
so can you try it please and get back to this thread with a reply, thanks"

In reply to you, yes I agree with your findings.
Well done in noticing the work-around.

The slant takes me back to my early analogue tv repair years and correcting mis-syncing of line time bases.

Anyway the same try happened to me and so would also do to anyone else.
Best regards.

I don't get that slanty screen capturing, using Screeny. It always works for me, windows or full-screen.

But, others have reported that slanty problem.

It is discussed in the Puppy Forum somewhere, and I think they decided that one of the utilities that Screeny uses had to be upgraded.

Maybe it is a video-card thing? I have Intel video on all my PCs.

[BarryK]

It didn't recognize my ethernet initially so it had to be set up with Simple Network Setup.

Code: Select all

Ethernet controller		: Intel Corporation 82579LM Gigabit Network Connection (rev 04)

I am surprised that your ethernet didn't work with UltraSNS.

Next time that you test, after bootup, wait a couple of minutes to be sure that it hasn't connected (watch the network icon in the tray).

If not, unplug the ethernet cable, wait several seconds, then replug it, see if that kicks usns into recognising it.

[blgs]

deleted

[blgs]

The information that you are providing is confusing me.

According to the jpg snapshot, as attached on page 95, your boot-partition is sda1 and working-partition is sda2.

However, in a later post you have said that you are updating an installation in mmcblk0

Both are correct.

sda1 and sda2 is the usb stick. mmcblk is the drive in my netbook. Installation on my netbook fails every time.

I managed to install it on a usb stick but after one or two reboots the same error occurs.

Version 1.0.8 operates perfectly.

Just a quick note: I think that I have discovered the cause of your problem.

It is because /.fsckme file exists when booting. I will post about this soon.

Got it! Will be fixed in next release.

The problem was, that $WKG_FS was not available in /sbin/fscheck in the initrd.

The fix requires this at line 328 (or thereabouts) in the init script:

Code: Select all

export BOOT_FS WKG_FS

The bug arose because those variables are no longer in BOOT_SPECS file.

Thanks for hanging-in-there providing feedback. Due to your help, a bug is fixed!

No issue. Keep in mind, I'm just a simple user an not a developer. I only can raise issues when I have got one, someone else has to solve it.

Keep up the good work regarding developing EasyOS.
Although it's an experimental distro, I use it as my daily driver on my netbook.

kind regards,
blgs

[rufwoof]

Changed my setup for the easy container to instead of launching fullscreen, I've used the screen option to size it to my display size, less the height of the normal jwm tray. I've also set Xephyr1 in my jwmrc to not show the window title or border. That way when the container is running I have two jwm trays at the bottom of screen, stacked on top of each other, with the lower tray being the main systems and the upper tray being the containers. And when a container window is maximised it starts at the top of screen as per any other window. Something like the attached

I am trying to get my head around whether that is a good idea or not!

Just looking at it, it might be confusing?

It might be one of those things where you have to use it to really decide.

Nice having the main systems rox readily to hand in the double height tray. Have that open in a container folder area and you move/edit files between the main desktop and container. So far I haven't expended much effort in 'merging' the two trays, other than having the container showing the clock, main tray showing the usual speaker, xload ..etc. But usage wise its nice IMO. But yes could be confusing for neubs.

Edit : another screenshot (clickable thumbnail)


Adding a <Outline> tag to jwmrc-theme for the tray(s) both inside and outside of the container better merges the two into a more seemingly single tray (no darker border that otherwise has a line between the two).

[BarryK]

Version 1.0.13 is out:

http://bkhome.org/news/201903/easyos-ve ... eased.html

The main reason for 1.0.13 is bug fixes, and 1.0.11 has been removed.

Lots of things still on the to-list!

[mikeslr]

wdt "I too would vote for continued iso, I use for install, not to burn to
optical disk" +1

BarryK "I will encourage newcomers to wait until 1.0.13 is released."

No need to worry. 90% or more of newcomers are Windows refugees accustomed to having their hands held. dd sends up a big red flag. "Pick the wrong drive and you've over-ridden your only operating without any assurance that its replacement will function".

Countless hours and unforeseen mental resources may be spent by developers bringing a new idea to fruition. But the adage "Build a better mouse-trap and the mice will beat a path to your door" isn't true. To become more than an odd toy for specialists a product must be easy: easy to build or it won't be built; easy to use or it won't be used.

Even your easydd isn't easy. It kept telling me that I needed to install pupmessage or gxmessage --already installed-- until it dawned on me "maybe you have to drop the img on the script".

ISOs may have originated with CD-Burners. But they are now a ubiquitous package for deploying operating systems to users without regard to how or where a user may choose to implement the system. Applications exist to decompress ISOs to USB-Sticks and hard-drives with fail-safe routines. Puppy users can just mount them and manually create frugal installs, safely and where wanted, in a matter of minutes.

Perhaps defer publishing ISOs until you are ready for feedback from the masses.

[BarryK]

What about the continuously ongoing flickering of the flash stick's light (that does not stop even if the OS seems to be 'idle'), in view of your previous warning remarks about the sticks' limited durability (ca. 1000 read/write cycles, indeed managed by appropriate firmware) and also about the risk of damaging interfaces by some usb-sticks whose firmware uses to run hot?

I think that is a temporary thing, with ext4. Explanation here:

https://askubuntu.com/questions/402785/ ... -and-solut

Easy 1.0.13 has a 640MB ext4 working-partition, that is expanded to fill the drive at first bootup.

The 640MB filesystem was created with the 'mke2fs' utility, and perhaps it has defaulted to the "lazy" writing mentioned in that link.

At first bootup, the 'resize2fs' utility is used, but looking at the man page, there is no option for turning off that "lazy" behaviour.

[Billtoo]

I installed to the hard drive:
Distro: Easy Pyro64 1.0.13

No problems so far,
Thanks.

EDIT:
I used the method described on your blog to upgrade:
Distro: Easy Pyro64 1.0.14

Thanks

[scsijon]

To scsijon,

"Rodney, I had the same problem when capturing from my browser until I put the browser into full screen (maximize) mode,
it apparently doesn't like to capture partially complete screens,
so can you try it please and get back to this thread with a reply, thanks"

In reply to you, yes I agree with your findings.
Well done in noticing the work-around.

The slant takes me back to my early analogue tv repair years and correcting mis-syncing of line time bases.

Anyway the same try happened to me and so would also do to anyone else.
Best regards.

I don't get that slanty screen capturing, using Screeny. It always works for me, windows or full-screen.

But, others have reported that slanty problem.

It is discussed in the Puppy Forum somewhere, and I think they decided that one of the utilities that Screeny uses had to be upgraded.

Maybe it is a video-card thing? I have Intel video on all my PCs.

Barry, I tried the method in the other message but it didn't work for me. The method I mention above was the only thing I found that worked, and I also only use intel nowadays although I do have others as cards to test with.

[scsijon]

Changed my setup for the easy container to instead of launching fullscreen, I've used the screen option to size it to my display size, less the height of the normal jwm tray. I've also set Xephyr1 in my jwmrc to not show the window title or border. That way when the container is running I have two jwm trays at the bottom of screen, stacked on top of each other, with the lower tray being the main systems and the upper tray being the containers. And when a container window is maximised it starts at the top of screen as per any other window. Something like the attached

I am trying to get my head around whether that is a good idea or not!

Just looking at it, it might be confusing?

It might be one of those things where you have to use it to really decide.

What about having the ability to have container windows one size smaller than the main window by default when first opened and then you have the ability to set for maximize or not, depending on what you want to use it for. Something like main window is 2048x1920, container windows start as 1920x1080?

[scsijon]

Ah yes, does anyone know, where do I set sakura's default screen size in a container? I can't find any that work when the desktop container is closed and a new one opened.
thanks

[BarryK]

Another one! Version 1.0.14:

http://bkhome.org/news/201903/easyos-ve ... eased.html

Due to ongoing issues with UltraSNS, decided to go back to NetworkManager. USNS is still there, as are all the others, SNS, etc., but NetworkManager is now the default.

NM was used in 1.0, and had the least problems, as I recall.

[rufwoof]

Ah yes, does anyone know, where do I set sakura's default screen size in a container? I can't find any that work when the desktop container is closed and a new one opened.

Can't see that as a option in the right-mousepress/options within sakura, nor within /root/.config/sakura/sakura.conf ... sakura --help however indicates it supports --geometry and that seems to be in characters (not pixels) for the sizing, but pixels for the location i.e. sakura --geometry 40x10+400+300 creates a sakura window 40 characters wide by 10 characters deep and X pixel offset 400 and Y pixel offset 300.

Sakura is a bin in /usr/bin/sakura, so for a permanent sizing I'd be inclined to rename that to sakura.bin and create a sakura script in its place constaining something like

Code: Select all

#!/bin/sh
sakura.bin --geometry 40x10+400+300 "$@"

[rufwoof]

What about having the ability to have container windows one size smaller than the main window by default when first opened and then you have the ability to set for maximize or not, depending on what you want to use it for. Something like main window is 2048x1920, container windows start as 1920x1080?

Operationally I'm only using the equivalent of just the easy (Xephyr) container myself now ... to have two desktops (main real root and another restricted root desktops). For me the double tray choice with the containers titlebar deactivated works really well. Simplifies things a lot as well having just the single choice. So much so I have my own script for the container now .. that could also be worked into other Puppy's. I'm using pflask within that (so for other Puppy's (pflask binary is already included in EasyOS) that would need to be compiled/installed (it has good instructions and is easy to do)).

Code: Select all

#!/bin/sh

######################################################

# Change these as required ...

# Folder where changes.sfs is stored
CHANGES_SFS_LOC=/mnt/sda1/easy/easyremastered-1.0/home/shared
# Where the main easy.sfs is located
EASY_SFS=/mnt/sda1/easy/easyremastered-1.0/easy.sfs
# dpi setting for container
DPI=144
# Container screen geometry, i.e. actual screen size with the Y value reduced
# by the jwm tray height (28 jwm tray on my 1440x900 resolution setup)
SCR=1440x872

######################################################

# Xephyr parameters
XP="-resizeable -dpi ${DPI} -nolisten tcp"
XP="${XP} -screen ${SCR}+0+0"
XP="${XP} -title Container -name Xephyr2"
	
# pflask parameters
PF="--keepenv --no-netns --no-userns"
PF="${PF} --mount=bind:/etc/machine-id:/etc/machine-id"    # firefox needs this
PF="${PF} --mount=bind:/etc/resolv.conf:/etc/resolv.conf"  # dns (internet) 
PF="${PF} --mount=bind:/dev/snd:/dev/snd"
PF="${PF} --mount=bind:/dev/mixer:/dev/mixer"
PF="${PF} --caps=all,-sys_chroot"
PF="${PF} --chroot=${CHANGES_SFS_LOC}/top"	

# cd to where changes.sfs is located
cd ${CHANGES_SFS_LOC}

# Avoid double click 2 instances
N=`date +%s` # Seconds since January 1970
if [ -f /tmp/container.run ]; then
	L=`cat /tmp/container.run`
	D=`expr $N - $L`
	if [ $D -lt 2 ]; then
		echo "Aborting : use only a single click to run $0"
		exit
	fi
fi
echo $N >/tmp/container.run

# Check required programs are available
[ -z `which popup` ] && xmessage Requires popup && exit
[ -z `which Xephyr` ] && popup Requires Xephyr && sleep 3 && killall popup && exit
[ -z `which pflask` ] && popup Requires pflask && sleep 3 && killall popup && exit
[ -z `which unshare` ] && popup Requires unshare && sleep 3 && killall popup && exit
[ -z `which chroot` ] && popup Requires chroot && sleep 3 && killall popup && exit
[ -z `which capsh` ] && popup Requires capsh && sleep 3 && killall popup && exit
[ -z `which empty` ] && popup Requires empty && sleep 3 && killall popup && exit
[ -z `which sakura` ] && popup Requires sakura && sleep 3 && killall popup && exit
[ -z `which jwm` ] && popup Requires jwm && sleep 3 && killall popup && exit
[ ! -f changes.sfs ] && popup Requires changes.sfs && sleep 3 && killall popup && exit
[ ! -f ${EASY_SFS} ] && popup "Missing ${EASY_SFS}" && sleep 3 && killall popup && exit

# Create a separate X instance so isolated from the main real root X
T=`ps -ef | grep Xephyr2 | wc -l`
if [ $T -ne 2 ]; then
	Xephyr :2 ${XP} &
else
	echo "Aborting as Xephyr2 is already running"
	exit
fi

# Create a changes folder, sfs mount point for easy.sfs and top layer folders
ACTIVE=0
T=`mount | grep '${CHANGES_SFS_LOC}/sfs'`
[ ! -z  "${T}" ] ACTIVE=1
T=`mount | grep '${CHANGES_SFS_LOC}/top'`
[ ! -z  "${T}" ] ACTIVE=1
[ ! -d top ] && mkdir top
[ ! -d sfs ] && mkdir sfs
# Start with a 'clean' snapshot of changes
[ ! -d changes ] && mkdir changes
if [ $ACTIVE -eq 0 ]; then
	[ -d changes ] && rm -rf changes
	DISPLAY=:2 popup "unsquashing changes.sfs "
	urxvt -g 70x4+10+10 -bg '#09A0FF' -e unsquashfs -f -d changes changes.sfs
fi

# To remount a already mounted, we use the -r (read) parameter
T=`mount | grep '${CHANGES_SFS_LOC}/sfs'`
[ -z  "${T}" ] && mount -r -t squashfs ${EASY_SFS} sfs

# aufs mount combining changes and sfs folders -> top
T=`mount | grep '${CHANGES_SFS_LOC}/top'`
[ -z  "${T}" ] && mount -t aufs -o br=changes:sfs none top

# create a script to run inside the chroot (i.e. must be a script, not a bin)
echo "#!/bin/sh" >top/init
echo "DISPLAY=:2 export DISPLAY" >>top/init
echo "sakura --geometry 1x1 -x killall sakura # wake up Xephyr gtk/dbus" >>top/init
killall popup
echo "seamonkey &" >>top/init
echo "jwm" >>top/init
chmod +x top/init

sync
killall popup

# chroot dropping chroot capability (to prevent chroot'ing out of the chroot)
# and using another X session (to isolate it from the main X session)
# chroot (pflask makes things easier) into the top folder applying restrictions 
# We use the main sfs as our base for the chroot, so chroot has very low overhead
DISPLAY=:2 empty -f unshare -m pflask ${PF} -- /init
PID=$!

# Tidy up after closing.
# The above falls through to here, so we need to monitor for when that ends
# kill -0 ... checks for existance (not very intuitive!) 
while kill -0 $PID >/dev/null 2>&1
do
	sleep 2
done
umount top
umount sfs
rm -rf changes.previous
mv -f changes changes.previous
killall Xephyr
# leave changes.previous in case we want to mksquashfs a new 'clean' changes.sfs
rmdir top sfs

exit
######################################################
	Everything below the last exit will be ignored i.e. are comments
######################################################
"
Change log :

	Rufwoof. 20190312 : 12th March 2019 initial version

Notes : 

Run browser (desktop) using a combination of

	unshare (mount points), 
	chroot (isolation)
	capsh (chroot capabilities dropped - to block chroot'ing out of chroot)
	using Xephyr (X separation)
	
Main easy sfs is used as the base for the chroot stores changes in a separate
changes folder i.e. low overheads, easily reset to 'clean'

Uses pflask https://github.com/ghedo/pflask that simplifies chroot'ing

Note that I've tweaked this to fit my 1440x900 display size/resolution and added
into ~/.jwm/jwm-personal a group clause that sets Xephyr2 (the name allocated
to the Xephyr window above) to have no border and no title i.e.

	<Group>
	  <Name>Xephyr2</Name>
	  <Option>noborder</Option>
	  <Option>notitle</Option>
	</Group>

 I've also adjusted the Xephyr -screen parameter size so the containers jwm
 menu/tray sits just above the main systems tray.
 Setting jwm tray Outline tag in jwmrc-theme to be the same colour as the tray
 background helps merge the two stacked tray into more seemingly one.
"
######################################################

That is less restricted in that it just uses Xephyr X session separation (so the container can't see the main sessions X), chroot with cap_sys_chroot capabilities dropped (so can't chroot out of the chroot). For me largely that provides adequate separation/security (browser run within a chroot that's not easily broken out of by chrooting out of that, where the session isn't saved and it can't see the real/main root sessions X windows, nor access files/folders outside of the chroot).

I've set it so that it automatically rolls back the main session at every reboot, and rolls back the container each time its started, and with the container auto started at bootup .. so clean at every boot, but where I can tweak things and re-create the clean sfs's as/when desired.

For me that simplification works well, but even then neubs might become confused with having multiple windows sharing the same view/monitor with some being restricted (inside the container) and others unrestricted. I guess one way to help reduce that confusion might be to colour the window borders differently. i.e. for general sharing/use, the base system would ideally come with a container sfs (changes) already pre-created. Being just the changes on top of the main easy.sfs however that's a relatively low overhead (could easily be less than 10MB additional size).

The other extension I've added is to run (very basic) checks agains the MBR (I boot using BIOS), grldr, vmlinuz, initrd, main sfs and containers sfs (md5sum's) at startup, so a indicator that they haven't been tampered with (intrusion detection).

I've adjusted my two trays so that they mostly vertically align

[Sage]

ISOs may have originated with CD-Burners. But they are now a ubiquitous package for deploying operating systems

Yes, indeed, mike. Apart from the RPis, this is one of the very, very few to buck the trend. Not entirely sure why BK wants to exclude/alienate the mainstream punters? A personalised hobby project is entirely reasonable, but this one is promulgated on DW to the wider community?

[blgs]

Frugal Installation of EasyOS 1.0.13 and EasyOS 1.0.14 on my netbook and usb is solved now. Also an upgrade from previous version (excl. 1.0.11) to 1.0.13 and 1.0.14 is solved now.

Quote
The Xorg GUIs are still there though, and can be turned on. They will be enabled by default for the non-English builds.
Unquote

How to enable it (XORG GUI's) for the English builds?

[Billtoo]

Installed to the hard drive:

VIDEO REPORT: Easy Pyro64, version 1.0.14

Chip description:
VGA compatible controller: NVIDIA Corporation GF108 [GeForce GT 430] (rev a1)

Requested by /etc/X11/xorg.conf:
Resolution (widthxheight, in pixels): 1024x768x16
Depth (bits, or planes): 24
Modules requested to be loaded: dbe

Probing Xorg startup log file (/var/log/Xorg.0.log):
Driver loaded (and currently in use): nouveau
Loaded modules: dbe dri2 evdev exa extmod fb fbdevhw glx shadowfb

Actual rendering on monitor:
Resolution: 1920x1080 pixels (508x285 millimeters)
Depth: 24 planes

[cthisbear]

I posted here on Whirlpool.

https://whirlpool.net.au/

833,928 registered members

EasyOS 1.0 Distrowatch review

https://forums.whirlpool.net.au/thread/2788863

Had to shoot down one of the only smarties.

But you know what I'm like....
never been nice...never been kissed...Not even twice.

As it is an Aussie forum it would be great if Barry
just introduced himself.
Probably a first that a dev says hello on that forum.

Think about it BK, although I know you are Mr modest by nature.
Probably why you are so respected here.

Cheers...Chris.

[rufwoof]

Run xinput list ... and identify the id of your AT keyboard (or touchscreen or mouse or whatever). Run xinput test-xi2 <id> for the id that you want to 'watch'. i.e. a basic/simple key/activity logger. Or ... use xdotool to stuff commands into other windows, or other simple methods to inject code/control. xdotool widowactivate 0x100004;xdotool type hello ... or whatever commands a hacker might want to run.

A browser flaw in a browser that permits remote control are relatively frequent events. Running as root and that directly opens up remote root access. Running in a chroot helps, but unless other measures are taken you can chroot out of a chroot (in past postings I've shown code to do that).

Puppy is only secure if run/used the 'right way', but equally other systems are similarly secure if run/used the 'right way'. In reality nothing is really secure. What EasyOS does is raise the bar, making it harder to penetrate. I've run penetration tests that attempted to break out of the easy containers chroot, monitor or stuff commands into the main systems keystrokes ... and those attempts were blocked. Combine that with checksum runs at startup to test the MBR (assuming BIOS), grldr (assuming grub4dos), vmlinuz, initrd, main sfs, container save area/sfs and that's similar to as though booted from a ro CD/DVD, you can be reasonably confident that a known clean version is being booted/used, at least up the point you open your browser and go online.

Similarly however other systems can be validate/started in a similar manner. In OpenBSD for instance I run mtree checks (checksums) against all bins/libs/etc. for intrusion detection purposes. I have a known clean /home rsync'd that I can restore so I know /home is also clean. I run the browser under a restricted userid that cannot su, has no access to setuid scripts ...etc. ... that along with OpenBSD's default folder/file permissions, pledge and unveil, radomisation of kernel, heap spraying barriers ...etc. is comparable (if not better) than EasyOS easy container. A main difference however is that OpenBSD's security in being more intense does weigh on performance. Slower to load browser, libre office ...etc. (disk IO in general as OBSD doesn't support squashed filesystems due to the security issues with such).

Perhaps best not to make 'never hacked' claims - as part of Puppy's security is its obscurity and such claims are like a red flag to a bull, somewhat attracts potential hackers interest/focus. And like anti-virus databases, there are the mirror image hackers databases out there, that more ideally its better to not get a listing/entry within those.