Please wait...
Meanwhile, in the world of software everyone likes (except for those emacs commies) ...
Bram Moolenaar, the lead developer of `vim`, died of an ongoing illness over this past weekend. He will be missed. Bon voyage Bram, may your buffers always be full and may you always know what mode you're in.
I've got a weird problem, and I can't tell whether it's my environment or something weird with FreeBSD.
I moved my FreeBSD installation from a private network to one of my "real" IP addresses. Changed the IP address, couldn't communicate with anything.
So I blew it away and started fresh. Still no dice.
It's a regular IPv4 adddress (72.0.224.94/29, gateway 72.0.224.89) and I've tried it both with and without an accompanying IPv6 address. Several attempts at installation. In every instance, I can ping everything in the world -- hosts on the same network, hosts on the Internet, hosts back at my house over VPN -- but I can't make a TCP or UDP connection to anything.
Thinking it had to be my hosting environment, I spun up a Linux on the same IP address, no problem at all.
What gives? Is there something Beastie does not trust about public IPv4 addresses and throws up a firewall or something?
Can't halp without "ifconfig -a" and "netstat -rn"
Sat Sep 09 2023 23:08:45 EDT from IGnatius T Foobar
I've got a weird problem, and I can't tell whether it's my environment or something weird with FreeBSD.
I moved my FreeBSD installation from a private network to one of my "real" IP addresses. Changed the IP address, couldn't communicate with anything.
So I blew it away and started fresh. Still no dice.
It's a regular IPv4 adddress (72.0.224.94/29, gateway 72.0.224.89) and I've tried it both with and without an accompanying IPv6 address. Several attempts at installation. In every instance, I can ping everything in the world -- hosts on the same network, hosts on the Internet, hosts back at my house over VPN -- but I can't make a TCP or UDP connection to anything.
Thinking it had to be my hosting environment, I spun up a Linux on the same IP address, no problem at all.
What gives? Is there something Beastie does not trust about public IPv4 addresses and throws up a firewall or something?
2023-09-05 09:29 from IGnatius T Foobar
For the record, I have no objection to Ubuntu. They had a more
polished end user experience for quite a long time. But now everything
has sort of caught up and is in a good steady-state, and I like the
idea of being more baseline.
I got started with Ubuntu, and it nearly kicked me back to Windoze.
When you design software and advertise it as n00b friendly, the #1 feature it needs to posses is that featured listed as available MUST FUCKING WORK.
See, if I play around with Gentoo, Slackware, KISS or Carbs I *will* run into something that does not work, but that is not a problem because I can solve it.
If I am Aunt Smith and they hand me Ubuntu and something does not work, I don't know how to solve it and the whole experience turns into a IT hell for me.
Ubuntu has become much better since the days in which I was first trying it, but nowadays if you want something n00b friendly you have plenty of options that are closer to a standard Linux.
Can't halp without "ifconfig -a" and "netstat -rn"
Can't halp at all, actually; the problem definitely seems to be in my hosting cluster rather than in FreeBSD.
On this particular machine, virtual machines seem to have an MTU of about 100 bytes when talking to the other machine (which also has the default gateway).
But it works fine from *containers* -- which is what I was testing with when I tried to find out whether Linux was behaving the same as FreeBSD.
I'm planning to build a completely new cluster soon so I'm not going to bother to try to troubleshoot it anymore; I'll just go back to running FreeBSD on the private network.
Another `systemd` win:
Today I learned that `systemd` has a built in superserver. It can listen on a port and spawn a server program directly, no need for `inetd` or `xinetd` in addition. That means I can get rid of `xinetd` for my telnet server, and use what I already have.
2023-09-21 02:03 from IGnatius T Foobar <ajc@citadel.org>
Another `systemd` win:
Today I learned that `systemd` has a built in superserver. It can
listen on a port and spawn a server program directly, no need for
`inetd` or `xinetd` in addition. That means I can get rid of `xinetd`
for my telnet server, and use what I already have.
Yeah, .socket units. Since it's there, I use it, but I still hate in principle that systemd is replacing everything. What was wrong with xinetd?
You could say the same thing for xinetd. What was wrong with inetd? You
could say the same for SysV init. What was wrong with /etc/inittab and /etc/rc?
I feel like we've gone through that already; I know some people don't care for systemd but I like it.
I feel like we've gone through that already; I know some people don't care for systemd but I like it.
FreeBSD had its 30th birthday this year. For 30 years FreeBSD has used the same rc system, with some impurrovements along the way. For 30 years, most sysadmin tasks have not changed.
Thu Sep 21 2023 09:11:03 EDT from IGnatius T FoobarYou could say the same thing for xinetd. What was wrong with inetd? You could say the same for SysV init. What was wrong with /etc/inittab and /etc/rc?
I feel like we've gone through that already; I know some people don't care for systemd but I like it.
I think there's a different attitude among people who run FreeBSD. The idea
of "add so-and-so to /etc/rc" isn't all that big a deal. And I kind of like
it; it reminds me of Sys III Init (probably because it *is* Sys III Init).
System V Init brought in this idea that you (or an installation script acting on your behalf) never have to edit an existing file; you can just add files and remove them. That's how you end up with all of the /etc/rc*.d/blah nonsense, which always felt sort of hackish and cobbled together. I've never liked it, which is part of why I was more than happy to see it replaced.
You see this kind of shit all OVER the place on Linux. There's never just a /etc/foo.conf , instead you get /etc/foo.conf.d/* and you can add and remove configuration snippets at will, and so can other programs. It's kind of annoying, but what's the alternative? If you break a configuration script with bad syntax, the whole thing stops working. That's acceptable on FreeBSD where the operator is expected to be smart enough to fix it. That stopped being acceptable on Linux when it went mainstream, and in retrospect was part of the cost of that happening.
Still, it's ugly when you see something like this in a configuration file:
## This was added by blurdybloop-installer, don't remove it
/etc/baz/do__something 42034
##
System V Init brought in this idea that you (or an installation script acting on your behalf) never have to edit an existing file; you can just add files and remove them. That's how you end up with all of the /etc/rc*.d/blah nonsense, which always felt sort of hackish and cobbled together. I've never liked it, which is part of why I was more than happy to see it replaced.
You see this kind of shit all OVER the place on Linux. There's never just a /etc/foo.conf , instead you get /etc/foo.conf.d/* and you can add and remove configuration snippets at will, and so can other programs. It's kind of annoying, but what's the alternative? If you break a configuration script with bad syntax, the whole thing stops working. That's acceptable on FreeBSD where the operator is expected to be smart enough to fix it. That stopped being acceptable on Linux when it went mainstream, and in retrospect was part of the cost of that happening.
Still, it's ugly when you see something like this in a configuration file:
## This was added by blurdybloop-installer, don't remove it
/etc/baz/do__something 42034
##
That is one of the reasons i hated to go back to penguin when i did ( drivers ).
Sat Sep 23 2023 00:26:01 EDT from IGnatius T FoobarI think there's a different attitude among people who run FreeBSD.
programs. It's kind of annoying, but what's the alternative? If you
break a configuration script with bad syntax, the whole thing stops
working. That's acceptable on FreeBSD where the operator is expected
to be smart enough to fix it. That stopped being acceptable on Linux
when it went mainstream, and in retrospect was part of the cost of that
happening.
If you use gigangic config files, and want to make a change on one, you:
a) Make a copy (config.conf.bak)
b) Edit the original to your heart's content.
c) Run a syntax check over the file you just changed (daemon -n -f config.conf or whatever)
d) Restart the daemon (rcctl restart daemon or whatever)
e) Have a beer while horses and hens enjoy a nice morning around you and then tell the Internet how it is done.