Puppy Linux Discussion Forum

Pugdog is the name I've given my cut down version of Fatdog's Bulldog.

I've compiled the kernel for that with localyesconfig so all modules are built into the kernel, and set it to optionally boot to the text console (vga=<VGA resolution>) or into the framebuffer. So with that I can boot to either pure console (no backgrounding/job control etc.), a pseudo terminal (so backgrounding/job control) and/or the framebuffer choice. With wifi net connection at bootup, along with KASLR kernel randomisation and mac randomisation. Oh and of course ssh (dropbear).

I've just dropped in fbvnc - framebuffer vnc, so booting into a 1366x768 sized framebuffer (my laptops resolution) I can use that to vnc into my desktop Fatdog (I've used xrandr on the Fatdog system to scale its 1440x900 to 1366x768 so that when I do vnc into it from my laptop its nicely full screened). No mouse (or sound) but I can textually control (in a limited way) the desktop from that Pugdog boot. Chrome etc looks OK, pretty much the same as standard vnc - but without the 'tightness' i.e. frame refreshes when watching a youtube video in chrome are a little laggy/jerky. Combined initrd.xz and vmlinux (bzImage) is just marginally over 8MB

The fbvnc was sourced from https://github.com/zohead/fbvnc I initially just compiled that using standard make and dropped the binary and libs into my pugdog - more just to see if it would work. Need to ideally compile that statically (musl and perhaps even upx'd) - but I've struggled to do that. Any tips ?? (I've got gcc static version OK, but musl-gcc complains about linux/input.h)

Thanks James. 39492 bytes when upx'd with --ultra-brute --best

Near the full build (all bar actual initrd) here ...
viewtopic.php?f=52&p=6629#p6629

rufwoof wrote: ↑Wed Sep 30, 2020 10:14 am The fbvnc was sourced from https://github.com/zohead/fbvnc

This doesn't work very well for me. I used the original source from Ali Ghoulami (https://repo.or.cz/fbvnc.git) but it doesn't have VNC auth support. So in the end I merged the two of them: I took zohead's code and applies the upstream patch from Ali. It seems to work but I have only tested lightly.

If you want to test, the patch is attached (apply it on top of zohead's git checkout).

jamesbond wrote: ↑Fri Oct 09, 2020 5:00 pm

rufwoof wrote: ↑Wed Sep 30, 2020 10:14 am The fbvnc was sourced from https://github.com/zohead/fbvnc

This doesn't work very well for me. I used the original source from Ali Ghoulami (https://repo.or.cz/fbvnc.git) but it doesn't have VNC auth support. So in the end I merged the two of them: I took zohead's code and applies the upstream patch from Ali. It seems to work but I have only tested lightly.

If you want to test, the patch is attached (apply it on top of zohead's git checkout).

Thanks James. Applied the patch and musl compiled (along with applying upx --ultra-brute) and it seems to be working OK. I've changed the code in fbvnc.c as per the attached - that works well for me.

rufwoof wrote: ↑Sat Oct 10, 2020 7:18 pm Thanks James. Applied the patch and musl compiled (along with applying upx --ultra-brute) and it seems to be working OK. I've changed the code in fbvnc.c as per the attached - that works well for me.

Thanks. I took your patch but I can't apply all of it, since some of them are keyboard-layout dependent (e.g. your ~@ are activated by AltGr, I suppose that's a UK keyboard layout; in my case (US keyboard layout) ~@ are activated by Shift key).

Attached is the part that adds functions keys part of your patch.

Tunnelling raw framebuffer using a light/fast fbvnc through a ssh tunnel where compression is turned on does seem to work better for me than using tigervnc. Wondering (suspecting) that may be due to not attempting to compress already compressed data content? i.e. if the output from the vnc server is already compressed and that's being conveyed over a ssh link (tunnel) that is using compression, then there's a additional overhead of attempting to (or actually applying) compression of already compressed data/content (that could even lead to slight data enlargement and involves CPU cycles).

Our internet feeds down at 100Mbs, uploads at 10Mbs. Our wifi also runs at 10Mbs. So the desktop (Fatdog desktop server via vnc) that is hard wired, can download files at 100Mbs, and with my laptop (wifi) being fed the screen contents. I also typically set up sshfs mounting of the desktop, so the servers folders appear to be just the same as local folders on the laptop. That's like having the laptop that's wifi net connected being able to download files at 100Mbs, upload at 10Mbs (but where accessing the files is also 10Mbps i.e. through sshfs).

Other benefits of using a thin client (Bulldog style) laptop that vnc's to a Fatdog desktop server through a ssh tunnel is that whilst out and about that detects/flags man in middle attacks (ssh will flag that the servers key had changed). There's also no eavesdropping (as its all tunnelled). As part of setup/bootup I run a script that randomises the MAC, so a fixed mac can't be tracked from location to location. I've also turned KASLR on, so the kernel isn't fixed in location in ram, but is randomly distributed. Yet another benefit is having tmux like functionality of being able to disconnect/shutdown the laptop, and later reconnect very quickly, possibly even from another device, and have the gui desktop exactly the same as how it was left (or to where it had moved on to, such as a kernel compile having completed or large download finished). Whilst the (ssh exposed) Fatdog server can be relatively secure, such as booting using multi-session saves from/to DVD. Very much like secure cloud computing - but where you control the 'cloud server(s)' and routing.

Increasingly 'the cloud' is becoming more restricted, perhaps unlimited downloads/content access to the home (hard wired) server, but limited downloads and access from mobile devices (wifi hotspots often restrict bandwidth/data volumes and/or content accessibility). Recently for instance GoogleDrive is immediately blocking sharing of certain files that I upload to share, such as initrd's. When you entrust to the cloud (microsoft/google/etc.) then not only are you paying for that in the way of 'yourself', but increasingly in the way of 'your data' ... becoming "owned" by others. Fatdog has the capacity to provide "Liberty" and security

I do like a thin client such as if specifically compiling the kernel with localyesconfig - so no other modules other than the ones required are built into the kernel. Smaller code = less attack vectors = more secure. Modules are many and each/any of which, in being just normal 'code', could be loaded and run for ulterior purposes, or where a flaw in one could have that being loaded and the flaw exploited. Again, Fatdog as a "tool-chain" ... is outstanding

I have so much to learn from you guys! @rufwoof, I really enjoy these detailed explanations of what you've done as it gives me things to research. Are you in the infosec field?

m1k3 wrote: ↑Sun Oct 11, 2020 1:11 pmAre you in the infosec field?

Nah! Just a man outstanding in his own field ... (surrounded by cows ). [Kidding ... just a couch potato]. Retired from all that infosec many, many, many moons ago. Now rapidly approaching actual retirement years

Well, your mind is very sharp so you still have that going for you.

jamesbond wrote: ↑Sun Oct 11, 2020 1:02 am

rufwoof wrote: ↑Sat Oct 10, 2020 7:18 pm Thanks James. Applied the patch and musl compiled (along with applying upx --ultra-brute) and it seems to be working OK. I've changed the code in fbvnc.c as per the attached - that works well for me.

Thanks. I took your patch but I can't apply all of it, since some of them are keyboard-layout dependent (e.g. your ~@ are activated by AltGr, I suppose that's a UK keyboard layout; in my case (US keyboard layout) ~@ are activated by Shift key).

Attached is the part that adds functions keys part of your patch.

Thanks James.

The Alternative Graphics key (Alt-Gr) that is to the immediate right of the spacebar, where US keyboards just have a second 'Alt' key, is a key that enables other characters to be 'typed' relatively easily. For instance on my UK keyboard pressing-holding alt-gr and pressing the 2 key prints a power of 2 (small supertext 2). Alt-Gr 3 prints the Euro currency symbol. i.e. keys that aren't standard keys on the keyboard. The extra code (that you left out) is more a European type thing, for the other 'weird' alphabetical characters in other languages, such as two dots above a letter/symbol.

No harm if left in or left out really. I've added // Europe .... and // ... end of Europe comments at the top/bottom of that code section within my copy, so that section could be commented out, or uncommented as desired/appropriate.

rufwoof wrote: ↑Wed Sep 30, 2020 10:14 am

Pugdog is the name I've given my cut down version of Fatdog's Bulldog.

Do you mind sharing a copy of that bulldog ?

Luke wrote: ↑Sun Nov 15, 2020 12:59 pm

rufwoof wrote: ↑Wed Sep 30, 2020 10:14 am

Pugdog is the name I've given my cut down version of Fatdog's Bulldog.

Do you mind sharing a copy of that bulldog ?

Hi Luke.

It's highly machine/hardware specific. Much of Puppy is modules/firmware to accommodate a broad range of hardware (AMD/Intel/types of network cards/display etc. etc.). Remove those to just leave what you actually have and the size drops massively. So it would be pointless for me to share a file for my Bulldog as it simply wouldn't work in 99.999% of cases due to differences in hardware being used. You have to build it yourself, and bearing in mind that once built for a particular system/hardware it isn't portable.

Basically I use Fatdog as the build-tool, and compile a kernel (and busybox) and fundamentally that's pretty much it, other than the init script. Along the lines of ...

viewtopic.php?p=6922#p6922

Again however that .config is tuned to my kit.

What you have to do is boot Fatdog (or whatever), load the devx sfs (so you can compile etc.) grab the kernel.org source files (which the script in that link does) and then the key element is to use make localyesconfig ... after having used/attached as much hardware (usb's etc.) that you use, so that the relevant modules will have been loaded. That 'make localyesconfig' build method then uses all of that information to construct a appropriate .config file, so when you then run "make" the kernel is built with just those.

After built once, I then revisited that, i.e. run 'make menuconfig' and then go through the many many options seeing what I could further remove. Very much experimental. Whilst the first compile does take a while, those revisits tend to compile relatively quickly (few minutes). Mine now builds to around 5MB in size which is about as lean as I can get it ... to provide boot to cli with wifi net connect capacity and ssh. From there you can build up whatever system around that as you see fit.

If you don't fancy getting into kernel compiling etc then perhaps a good choice of start point is wiak's weedog build scripts viewtopic.php?p=616#p616 (which builds things far far quicker than building a puppy using woofce).

Hello, Rufwoof! I have been following your publications. For the past 10 days, I have been using DebianDog Sid which uses overlayfs. A beautiful job! You have no idea of my satisfaction in compiling the 5.4.80 kernel, without aufs! I really liked the overlayfs. I would be very pleased if I managed to use overlayfs on FatDog64! How nice it would be if there was such a version. I know that what I write to you is a little out of the topic of this topic. I look for those who have the same curiosity as me, but much more knowledge.

"Innovating towards simplicity, leads to freedom and less dependence"

Fatdog's stability/cofiguration/setup is great as-is. Moving away from aufs would just jeopardise that as well as lose the ability to dynamically load/unload sfs's 'on-the-fly'. I'm a experimentalist by nature ... a.k.a if it ain't broken then meddle/break it. So what I did was use Fatdog's Bulldog as a base, and stripped that down .. to where now I've a Pugdog that is based on mounting sfs(s) and sym linking their content into / ... tinycore style. No overlays/layering at all.

As wanderer has indicated you can in effect load/unload those sfs's on the fly however viewtopic.php?p=10776#p10776 .. via simple folder renaming.

rufwoof wrote: ↑Sun Oct 11, 2020 9:44 am

I do like a thin client such as if specifically compiling the kernel with localyesconfig - so no other modules other than the ones required are built into the kernel. Smaller code = less attack vectors = more secure. Modules are many and each/any of which, in being just normal 'code', could be loaded and run for ulterior purposes, or where a flaw in one could have that being loaded and the flaw exploited. Again, Fatdog as a "tool-chain" ... is outstanding

I'm wondering what limitations this might pose. I was thinking of using Pugdog as sort of a minimal boot system which I could load and quickly chroot into a fuller version of puppy linux. Perhaps Bulldog would be better for that or maybe a cutdown version of TazPup. So for instance, can I load the kernal modules by mounting a z and f drive or would such modules/firmware not be loadable in pugdog?

s243a wrote: ↑Mon Nov 30, 2020 10:23 pm

I'm wondering what limitations this might pose. I was thinking of using Pugdog as sort of a minimal boot system which I could load and quickly chroot into a fuller version of puppy linux.

That's what all frugal Puppy's do already. Just that Pugdog stays running in the initramfs rather than switch-rooting out of it. My pugdog can equally setup a normal Puppy like filesystem and chroot or switch-root into that, or kexec, or kvm/qemu boot, ... or whatever. Once you have cli/wifi-net connect/ssh you're pretty much free to build whatever you like on top of that.

The primary difference is that Pugdog is built (kernel) for the specific machine, so isn't portable, whilst Puppy's initramfs is more portable. Those modules/firmware add typically around 80MB of compressed firmware/modules, most of which wont be used (and could be a security risk).

Rufwoff:
I followed your instructions (make localyesconfig and make -j2) and compiled the 5.4.78 aufs kernel again. Vmlinuz got 7.7 Mb. Initrd has 5,8 Mb and fd64.sfs 216 Mb (without the fat). No firmware file.
The result: Everything I use worked perfectly! There is no more FatDog64 but the GalgoDog64! : The system starts up much faster. My libreoffice, gimp, browsers, Clamav and other programs, are of the ROXapps type. Each browser is pre-configured and installs after startup, according to my choice and dies in shutdowm. It always runs in RAM and I don't use savefiles. The customizations are included in the fd64, together with the wine that has 205 Mb, run the heaviest games without problems.

Mitigating vulnerabilities worked normally.
Thank you for your instructions!