Re: [DNG] questions further into networking
On 1/30/22 20:05, o1bigtenor via Dng wrote: Greetings (Growing out of the 'Configuring ethernet port of ipv6' thread.) I have been considering setting up a 'Pihole' to enhance my network here. Is a Pihole a useful addition into a ipv6 network or ? I've been using it for quite a while. It blocks about 30-45% of my daily DNS requests IPv4 & IPv6 It is quite an effective DNS based pre-filter And you get warnings like this 2022-01-28 00:00:48 RATE_LIMIT Client fd00::9b3a:1467:d7db:58c9 has been rate-limited (current config allows up to 1000 queries in 60 seconds) which might help you in case of problems. (In this case this was my laptop starting an odd job) Cheers Mike ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] What is your take on finit?
Didier Kryn said on Mon, 31 Jan 2022 10:27:53 +0100 >Le 29/01/2022 à 21:00, k...@aspodata.se a écrit : >> I don't see the point in letting init do serious process monitoring. >> Just use a minimal init and startup a separate process monitoring >> daemon (or what theese things are called). >> >> ... >> I don't see the point, learn to write good deamons. It seems the need >> to use theese process monitors has sprung up from the availability >> of shitty deamons. >> In my view, when a deamon dies by any other cause than from your >> will then it shall die so hard that it causes a major headacke and >> the shitty programmer should be publicly flogged as a reminder and >> example to other programmers -- well not really, but you get my >> point. >> >> Most deamons I have run, they just run, they don't need a process >> monitor except me. >> > I fully share this pov. I'm happy with sysvinit or Busybox init. >If I was still active, and needing to write daemons, I would certainly >welcome improvements on the following points: > > - simplify start/stop scripts and find a better way to express >their dependencies Runit does that. > - help daemons ack when they're actually ready Runit goes one better, by allowing you to put tests in the run scripts of dependent processes to see when their dependencies are fully functional. The beauty is that YOU decide the meaning of "fully functional", not the daemon author, who might not understand your individual situation. > > Writing a self-daemonizing daemon in C was a routine when I was >still active, though I understand it could be more difficult in shell. But more difficult in Python. I try to stay away from C if Python does the job. I think Python3 plus its standard libraries are more secure than C code written by the error prone Steve Litt. As far as "routine", I would think it's a lot more difficult to have a program doublefork itself when finished than the 9 or so lines it takes to doublefork something else. I was unable to write a doublefork-something-else routine in /bin/sh. Maybe smarter shellscript people than I can do it, but I can't. >Also I like that the logs are sent to syslog. I'm pretty sure runit can send logs to syslog. > > But, as a user, I'm satisfied with sysvinit. Boot is so fast that >I've abandonned the use of suspend/resume. I'm pretty sure runit boots faster than sysvinit. Also, an excellent move is to use sysvinit for PID1, and use runit for most of the rest of your daemons. About writing good daemons... Sometimes, for my personal use, I want to write a quick and dirty daemon in Python, and if it dies have runit run it again. If I were to write a daemon where a crash would signify something terrible that needs to be investigated, it can be run as a one-shot by any init system. Whatever shellscript runs the daemon could end by getting $? and if it's non-zero, make a lot of noise. This could also be done if it's supervised. So I still say daemons are usually best run in the foreground and supervised by a supervisor. And therefore I'm not especially impressed by finit. Everything I said about runit in this email is also true of s6. SteveT Steve Litt Spring 2021 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] PHP 8.1 depends on systemd?
Hello Mark, It is a server so it runs stable pinned - but with additional testing sources for specific software too outdated in stable. Actually there is no problem with the package php8.1 itself but php8.1-fpm. I suspect it would work by installing first systemd-standalone-tmpfiles that provides systemd-tmpfiles. Nonetheless, I'll delay upgrading to PHP until 7.x are discontinued, not really in a hurry to add more systemd parts that are beyond the scope of an init system. Thanks for the tips. Regards ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] questions further into networking
On Mon, Jan 31, 2022 at 9:41 AM Michael Neuffer via Dng wrote: > > > > On 1/30/22 20:05, o1bigtenor via Dng wrote: > > Greetings > > > > (Growing out of the 'Configuring ethernet port of ipv6' thread.) > > > > I have been considering setting up a 'Pihole' to enhance my network here. > > > > Is a Pihole a useful addition into a ipv6 network or ? > > > I've been using it for quite a while. It blocks about 30-45% of my daily > DNS requests IPv4 & IPv6 > > It is quite an effective DNS based pre-filter > > And you get warnings like this > 2022-01-28 00:00:48 RATE_LIMIT Client fd00::9b3a:1467:d7db:58c9 has > been > rate-limited (current config allows up to 1000 queries in 60 seconds) > > which might help you in case of problems. (In this case this was my > laptop starting an odd job) > > Seems like to Pis are going to be needed for here - - - grin. One for a pihole and another for voip services (asterisk + ) Thank you for your help!!! Regards ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] questions further into networking
On Mon, Jan 31, 2022 at 2:42 PM Simon wrote: > > o1bigtenor via Dng wrote: > > > I have been considering setting up a 'Pihole' to enhance my network here. > > > > Is a Pihole a useful addition into a ipv6 network or ? > > (As already mentioned) The Pihole works at the DNS level, so it simply blocks > DNS lookups for “stuff you don’t want”. So it’s agnostic to the transport > layer - IPv4 or IPv6. > I can’t help thinking that one (of several) reasons for things like > DNSoverHTTPS, and as I recently read on another mailing list that (at least) > one of the TV streaming devices only works with the vendor’s DNS service is > to bypass protections like DNS filtering/blocking. > Hmmm - - - very interesting! When this (streaming device only works with the vendor's DNS) happens - - - is there a way to counter or change that particular behavior? (Fascinating what's all connected!!!) Regards ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] questions further into networking
o1bigtenor via Dng wrote: > I have been considering setting up a 'Pihole' to enhance my network here. > > Is a Pihole a useful addition into a ipv6 network or ? (As already mentioned) The Pihole works at the DNS level, so it simply blocks DNS lookups for “stuff you don’t want”. So it’s agnostic to the transport layer - IPv4 or IPv6. I can’t help thinking that one (of several) reasons for things like DNSoverHTTPS, and as I recently read on another mailing list that (at least) one of the TV streaming devices only works with the vendor’s DNS service is to bypass protections like DNS filtering/blocking. Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] IPv6 for dummies by a dummy (was: Configuring ethernet port for IPv6)
I hope that others might also contribute even questions and thereby a document in the 'how to' class is created. On Mon, Jan 31, 2022 at 5:03 PM Simon wrote: > > o1bigtenor via Dng wrote: > > > Not only do I want to echo mr Joel but for mr Simon. > > This gives great information - - - all together AND in a fashion that > > I think I may even be understanding this. > > Thanks, that makes it worthwhile having written it. > As you might have guessed, I’m in the IPv6 is good camp. Frustratingly my ISP > ran IPv6 trials several years ago but has since gone quiet - even though > their parent company (a larger ISP) rolled out IPv6 by default several years > ago ! > > > Please would you fashion perhaps 2 or three more messages for > > intermediate and maybe even extend this into more of the > > 'advanced' networking country. > > I’m not sure there’s all that much I can add. One of the problems of not > using it often enough is that I’ve forgotten a lot of what I learned when I > worked through the tunnelbroker certification - which BTW will (if it’s still > part of the deal) will get you what must be one of the geekiest tee shirts > ever created ! > snip > You will want to configure an IPv6 firewall. I used Shorewall for this - it’s > an amazing package. It’s still usable, but it’s time is now limited as it’s > deeply entangled with iptables which is now deprecated and replaced with > nftables. I imagine that at some point the iptables compatibility shim will > go away and that will stop Shorewall. > I am looking at (have the hardware waiting for pickup) running something like Pfsense or Opnsense for a firewall. It seems that either support ipv6 as well. snip > > > I am not needing ipv6 at present but likely this spring fiber optics > > are happening (finally some decent speed options) and they are > > in the process of moving to ipv6 likely within a year or so. I would > > prefer to know at least some more before I 'need' it. > > Good news then - the more ISPs do IPv6 the better. The main thing to remember > is that IPv4 vs IPv6 is orthogonal to the rest of the stack - the physical > layer underneath (fibre, ethernet, xDSL, cable, dial-up, damp string, carrier > pigeon, ...) and the session layers higher up (DNS, HTTP, SMTP, ...). > Things are not completely disconnected as things need to support the > differences - e.g. handling 128 bit long addresses, doing lookups as > well as A, and so on. But (and not speaking as someone who’s had to deal with > that), I think a lot of that is handled by the standard libraries. > Wondering about physical setup. I had thought of running my network (part of it at least) like this: WAN == router == firewall == managed switch == complicated network It has been suggested to me that I should combine the router and the firewall functions into the same machine. Which option (combining functions or separating functions) gives a more robust network? Where would a pihole function in this scenario? An air gapped machine is considered the most secure. Doing this makes updating the system more difficult and could make some tasks more difficult. (Business reasons for wanting as high a security as possible.) How secure can a system be made using firewall(s)? TIA ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] IPv6 for dummies by a dummy (was: Configuring ethernet port for IPv6)
o1bigtenor via Dng wrote: > Wondering about physical setup. > I had thought of running my network (part of it at least) like this: > > WAN == router == firewall == managed switch == complicated network > > It has been suggested to me that I should combine the router and > the firewall functions into the same machine. Which option (combining > functions or separating functions) gives a more robust network? > > Where would a pihole function in this scenario? > > My home network: WAN (modem) == router/firewall == switch == uncomplicated network The pihole resides as part of the uncomplicated network, plugged into the switch. My consumer router/firewall has unused ports; it could have gone in one of them. In any case, I'd recommend it being inside the firewall with the rest of the network. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] IPv6 for dummies by a dummy (was: Configuring ethernet port for IPv6)
o1bigtenor via Dng wrote: > Not only do I want to echo mr Joel but for mr Simon. > This gives great information - - - all together AND in a fashion that > I think I may even be understanding this. Thanks, that makes it worthwhile having written it. As you might have guessed, I’m in the IPv6 is good camp. Frustratingly my ISP ran IPv6 trials several years ago but has since gone quiet - even though their parent company (a larger ISP) rolled out IPv6 by default several years ago ! > Please would you fashion perhaps 2 or three more messages for > intermediate and maybe even extend this into more of the > 'advanced' networking country. I’m not sure there’s all that much I can add. One of the problems of not using it often enough is that I’ve forgotten a lot of what I learned when I worked through the tunnelbroker certification - which BTW will (if it’s still part of the deal) will get you what must be one of the geekiest tee shirts ever created ! One thing I didn’t cover is addressing, and how they are represented. https://en.wikipedia.org/wiki/IPv6_address gives a fairly decent overview - apart from perpetuating the myth that EUI-64 addresses are still common - they were deprecated a while ago. Then I can perhaps outline what you need to do to set up your own router supporting IPv6. On the ISP end you need the appropriate interface and software. So this may be PPPoE, or direct Ethernet with one of a number of configuration protocols, or ... So the first thing to do is sort out whatever combination of bits will get you connected. One of the problems is that there are a number of different components, that can be used in different combinations - so you’ll need to find out exactly what your ISP uses/supports. This is all from memory, so can’t rule out errors :-( In my case, it was a case of using a DSL modem and running PPPoE over an ethernet link. With PPP, LCP (Link Control Protocol) will negotiate the session with the far end PPP service, then the PPP package will configure the protocols you tell it to - IPCP (IP Config Protocol) for IPv4, IPv6CP for IPv6. Checking my notes, I then had to run a DHCPv6 client to get an IPv6 delegation - in this case asking for a /56 prefix. I manually/statically configured all this with scripts for expedience (we got static IPv6 allocations) - it’s possible to automate steps using features in some of the software, which has generally advanced since I last did this. So now we should have a working IPv6 link to the ISP and an IPv6 prefix. The link may just have a link-local address (starting fe80:) or it may also have a GUA (Globally Unique Address) as well - depends on the ISP setup and your own setup. So my script then added a GUA address to the PPP interface, a route to the internet via that link, and a different GUA to the internal interface. At this point, you should have a system that can route packets between an internal device and the internet. You will want to configure an IPv6 firewall. I used Shorewall for this - it’s an amazing package. It’s still usable, but it’s time is now limited as it’s deeply entangled with iptables which is now deprecated and replaced with nftables. I imagine that at some point the iptables compatibility shim will go away and that will stop Shorewall. You now need to configure devices on that internal network. You can do it statically - but that’s a p.i.t.a. So configure and start an RA daemon. Again, as this was a trial and we had static allocations, I just put the prefix in the config file and had my script bring up radvd. This is perhaps one of the steps that would be harder to automate since you need to pick a /64 prefix out of your (hopefully) larger delegation. And you also have the ability to run multiple internal networks with different prefixes. Once you startup the RA daemon, you should see clients auto-configure and be able to use your new IPv6 service. > I am not needing ipv6 at present but likely this spring fiber optics > are happening (finally some decent speed options) and they are > in the process of moving to ipv6 likely within a year or so. I would > prefer to know at least some more before I 'need' it. Good news then - the more ISPs do IPv6 the better. The main thing to remember is that IPv4 vs IPv6 is orthogonal to the rest of the stack - the physical layer underneath (fibre, ethernet, xDSL, cable, dial-up, damp string, carrier pigeon, ...) and the session layers higher up (DNS, HTTP, SMTP, ...). Things are not completely disconnected as things need to support the differences - e.g. handling 128 bit long addresses, doing lookups as well as A, and so on. But (and not speaking as someone who’s had to deal with that), I think a lot of that is handled by the standard libraries. Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] IPv6 for dummies by a dummy (was: Configuring ethernet port for IPv6)
tempforever said on Mon, 31 Jan 2022 21:11:55 -0500 >o1bigtenor via Dng wrote: >> Wondering about physical setup. >> I had thought of running my network (part of it at least) like this: >> >> WAN == router == firewall == managed switch == complicated network >> >> It has been suggested to me that I should combine the router and >> the firewall functions into the same machine. Which option (combining >> functions or separating functions) gives a more robust network? >> >> Where would a pihole function in this scenario? >> >> >My home network: > >WAN (modem) == router/firewall == switch == uncomplicated network > >The pihole resides as part of the uncomplicated network, plugged into >the switch. > >My consumer router/firewall has unused ports; it could have gone in one >of them. > >In any case, I'd recommend it being inside the firewall with the rest >of the network. Very soon I'll build myself an OpenBSD/pf firewall/router. At that time I might set up something like the following: 11.22.33.440.0/24100.0/24 INTERNET==SPECTRUM_MODEM_FW/ROUTERBSD/PF==WIRED_LAN \\ \=WIFI_ACCESS_POINT=Laptops 0.0/240.0/24 The preceding leaves the Spectrum modem/firewall/router/wifi open to the 20005 attack, but that attack can't go anywhere easily. I'll try very hard to disable the Spectrum's wifi. The OpenBSD/pf will protect the wired network from packets initiated from the Internet or from the wifi laptops. I might leave ports 80 and 22 open to the laptops so they can get house websites or ssh in. Also, I'll need to have them receive DHCP from somewhere, and try to configure the DHCP to specific MAC addresses. SteveT Steve Litt Spring 2021 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] What is your take on finit?
Le 29/01/2022 à 21:00, k...@aspodata.se a écrit : I don't see the point in letting init do serious process monitoring. Just use a minimal init and startup a separate process monitoring daemon (or what theese things are called). ... I don't see the point, learn to write good deamons. It seems the need to use theese process monitors has sprung up from the availability of shitty deamons. In my view, when a deamon dies by any other cause than from your will then it shall die so hard that it causes a major headacke and the shitty programmer should be publicly flogged as a reminder and example to other programmers -- well not really, but you get my point. Most deamons I have run, they just run, they don't need a process monitor except me. I fully share this pov. I'm happy with sysvinit or Busybox init. If I was still active, and needing to write daemons, I would certainly welcome improvements on the following points: - simplify start/stop scripts and find a better way to express their dependencies - help daemons ack when they're actually ready Writing a self-daemonizing daemon in C was a routine when I was still active, though I understand it could be more difficult in shell. Also I like that the logs are sent to syslog. But, as a user, I'm satisfied with sysvinit. Boot is so fast that I've abandonned the use of suspend/resume. -- Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] PHP 8.1 depends on systemd?
Le 29/01/2022 à 18:46, goli...@devuan.org a écrit : PHP is not relevant to my world but perhaps related to this thread? https://dev1galaxy.org/viewtopic.php?id=3331 AFAIU the name of the dependency, PHP isn't able to create a temporary file without the help or permission of Systemd. How scary! ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng