The officially official Devuan Forum!

fest3er

Member

Registered: 2022-07-06

Posts: 8  

Smoothwall Express

[I type a lot and have lots of thoughts, so this will be kind-of long.]

I'm the Smoothwall Express project leader. I had the temerity back in the early teens to modernize v3.0; in 2014, the project was plopped in my lap. Oops; I was just trying to be a nice guy. I updated much of the software (around 250 packages), fixed many latent bugs (many found while looking for something else [scroll, scroll, scroll, wait, what was that? Off-by-one? Oho! *That* explains that instability. Fix. Now where was I?]), fixed and twerked the web UI, made the build system re-entrant, make it installable and usable in VMs, and did other things. Through 11 updates in the following six years. The result has been a rock-stable firewall that runs for years without problems (for most users; a few have encountered oddities that I haven't yet figured out).

Smoothwall Express is a purpose-built firewall. The software is deliberately limited to minimize attack vectors. It was, and continues to be, designed for non-experts to use.

I'm attempting to 'port' Smoothwall Express to Devuan for two primary reasons. I despise systemd and the black hole it has become. Second, I just can't keep up with the changes to foundation pkgs (binutils, gcc, linux, etc.); it takes me far too long to update them. In time, I'll create a derivative of Devuan that is a, mmm, subset of Devuan, but makes use of Devuan's security updates.

So, I want to use Devuan. And it hasn't been so easy. I'm finally making some progress in making a smoothwall-express .deb that has dependencies for everything it uses by default (the usual instruction in the Debian documentation is 'find a similar package and adapt it for your purpose' which is rather less than useful. Alas, there are no pkgs (that I've found) similar to what I want to do. Debuild creates a .deb that mostly works; presently it stumbles when it tries to replace files that other pkgs have installed (inittab, dnsmasq.conf, et alia). Is there a recommended way to do that without having to worry about updates wiping out my changes?

Eventually, I'll have to change a lot of stuff to do it 'the modern way'. (It was open-sourced over 20 years ago, and sort-of based on linux-from-scratch.) For now, I'm trying to avoid having to do *everything* all at once. There are a few smoothwall-specific programs in use; the UI handles most of the daemon/feature controls via a setuid daemon that restricts access to things that require root access.

There is no desktop environment; I'd even eliminate dbus if I could. There are two users defined: 'root' and 'nobody'. I wish to build on others' work (Devuan) so I can concentrate on improving and expanding the firewall and filter capabilities.

So, are there any references that would help me figure out how to do what I'm trying to accomplish? Words of wisdom? Words of encouragement?

Neal

----

One thing I've been pondering for more than a few years is to extend sysvinit. The first computer I bought, in 1986, was an AT&T UNIX PC (SysV, demand-paged virtual memory, loadable drivers, etc.); I taught myself UNIX, C and KSH on it (which took a while because they are very different from TOPS-20, AOS/VS and VMS and the languages I knew up to that point). I've often wondered why no one ever used sysvinit the way it was intended: to start and control daemons and keep them running. Rather, they just used the Berzerkely way.

• Extend inittab's 'ID' field to near-arbitrary length so daemons can be referenced by their names

• Expand the run levels to 256 (levels 2-5 and 7-10 would be dead; 0, 1 and 6 would retain their traditional meanings)

• All daemons in a run level would be started in parallel

• Add command line options to init/telinit to stop/start/restart/enable/disable daemons, and extend that field in inittab

• &cetera

This would, of course, mean that daemons would not be allowed to daemonize themselves; their stdout and stderr would have to be dumped or directed to log files. Signals would have to be well-handled so daemons cannot interfere with each other. I know, 'tis a silly notion.