You are not logged in.
- Topics: Active | Unanswered
Pages: 1
#1 Re: Other Issues » [Solved] How to load nftables rules at boot? » 2021-03-27 20:09:20
Yes, that's right.
Cool. Thanks for confirming that. Another thing i'm starting to get my head around is fitting into place 
#2 Re: Other Issues » [Solved] How to load nftables rules at boot? » 2021-03-27 11:53:55
There are several kernel modules that provide the firewall functionality but the init script (or systemd unit file) is needed to load the user space process that actually runs the firewall.
That user space process being the nft "application" that reads in the rules and passes to the kernel part of nf_tables ?
#3 Re: Other Issues » [Solved] How to load nftables rules at boot? » 2021-03-26 18:02:45
Can i just check something and im still leanring about nf tables so could be way off.
If nf_tables is a kernel level module and likely to be loaded at boot time and active(assuming not explicitly deactivated the modules) , then is there any need to have a init.d script to start it ? Wont it start up and load rules then ? What am i missing ? Or is this just a belt and braces step to make sure any rules really are included at boot time ?
#4 Documentation » nftables advice? » 2021-01-28 14:47:51
- ifdv44
- Replies: 1
I'm still learning so be gentle.
It appears iptables is on the road to deprecation in the Debian repos and that nftables is the recommended replacement for maintaining a firewall on a machine. Is it safe to assume that Devuan will follow that (it appears to be the default install too) ?
I've never really poked at the firewalls on Linux until recently and a brief look at the syntax and documentation suggests the iptables rules are easier to read and that there is more documentation on them. However , while i can see the point in learning that, my time is limited and I'm looking for a clear guide to the syntax and some examples of nftables. I've been looking on the netfilter site and various other searches and I've gone a bit cross eyed. Any suggestions on where i might be advised to start learning from?. I dont want to lock myself out of the remote machine so will need SSH open at the minimum.
#5 Re: DIY » Linux ports of OpenBSD's ksh » 2021-01-09 22:05:13
The loksh package is derived from OpenBSD's KornShell implementation and so is audited and maintained by their devs.
It is very slightly "lighter" than mksh and also a tiny bit faster but it lacks support for here strings (here documents still work though). In respect of the original KornShell, that is significantly faster (it is the fastest of all the Bourne shells by some margin) but the ksh93 version in ASCII & beowulf is very old and has quite a few bugs — the new 2020 version in chimera/ceres fixes most of these and is under heavy development.
All three KornShell implementations are actively developed and maintained.
EDIT: loksh is the only one with bash-style PS1 support though, which I like.
Any quick and easy reference to the pros/cons of the three? I'm a KSH user at heart and haven't got to installing it and configuring it how i want yet so am open to improvements .
#6 Re: Hardware & System Configuration » /etc/os-release clarification ? » 2021-01-09 22:00:59
/etc/issue is traditionally the message that appears on the virtual terminals above the login prompt. And /etc/issue.net is traditionally the message for when you log in via ssh. They normally start with contents that might list the OS, but they can be set to whatever you want.
I had no idea /etc/os-release was a systemd thing... drat.
Slightly off topic, but this has raised another two questions.
By virtual terminals you mean TTY , and a log in via a serial console connection ?
So as I'm using SSH (via putty ) i'd not see the first one ?
#7 Re: Hardware & System Configuration » /etc/os-release clarification ? » 2021-01-08 13:36:57
/etc/issue is traditionally the message that appears on the virtual terminals above the login prompt. And /etc/issue.net is traditionally the message for when you log in via ssh. They normally start with contents that might list the OS, but they can be set to whatever you want.
I had no idea /etc/os-release was a systemd thing... drat.
It was with the aim of parsing the entry and comparing to one of the log in banner files called that i was driven to look at this , so might have got there eventually. The document I'm looking at seems to be working on the assumption systemd is being used so having to work out the alternatives and with Devuan's roots in Debian still popping up in the install it's tricky to know if i will break things by changing with out spending a lot of time digging and reading
#8 Re: Hardware & System Configuration » /etc/os-release clarification ? » 2021-01-08 13:31:27
If you're using grub-efi-amd64-signed and have ID=devuan in /etc/os-release, you'll boot to a grub prompt instead of a boot menu. That's because grub will expect the signed bootloader to be found under /boot/efi/EFI/debian, but your bootloader will be in /boot/efi/EFI/devuan instead.
Some third-party software that expects to see debian might complain or refuse to install. I don't have an example.
There's also /etc/issue, which is in most linux distros.
Thanks. I have a whole host of questions and further reading to do about Grub that I'll save for another time, but i appear to have installed Devuan without efi ...I think...it was two years or more since i installed so cant remember and looking around the grub files i cant see any mention or efi or signed things...
Anyway the /etc/issue file is perfect for my purposes. I assume at the next release that becomes ? :
Devuan GNU/Linux 4 #9 Re: Hardware & System Configuration » /etc/os-release clarification ? » 2021-01-08 09:05:52
See if you can guess who created the file. [Spoiler Alert!]
Read os-release(5) for the implementation details.
Note that any edits to the file will be over-written whenever the base-files package is updated. EDIT: actually dpkg might ask you what to do with it if it has been edited.
Thanks, that's interesting reading.
Sooo, if I was being a purist I'd try to ignore that file as it was driven by the systemd changes to Linux. I can see the reasoning behind having a file like that though irrespective of the boot approach. Is/was there an pre systemd equivalent and where would i find it on Devuan ?
edit, and I should ask, is there a known plan to Devuan-ise those two fields referencing Debian for the future ?
#10 Hardware & System Configuration » /etc/os-release clarification ? » 2021-01-07 20:16:14
- ifdv44
- Replies: 13
Probably a simple question, but I'm still learning about the deeper levels of a linux system.
my /etc/os-release is :
PRETTY_NAME="Devuan GNU/Linux 3 (beowulf)"
NAME="Devuan GNU/Linux"
VERSION_ID="3"
VERSION="3 (beowulf)"
VERSION_CODENAME=beowulf
ID=debian
ID_LIKE=debian
HOME_URL="https://www.devuan.org/"
SUPPORT_URL="https://devuan.org/os/community"
BUG_REPORT_URL="https://bugs.devuan.org/"I was curious as to what the references to Debian were for, and if i were to change them to Devuan , would i break anything ? I assume a simple update of the file in vi would be all I'd need to do to change it, there isn't another utility I'd need to do it with ?
Pages: 1
Board footer
