[DNG] Viewing file content (was Re: system administration of non-systemd distros and releases)
Hi,
Steve Litt writes:
> What could possibly be easier than vim /var/log/messages, or
> vi /var/log/messages, or emacs /var/log/messages, or
> nano /var/log/messages? And notice with the old way, you have a choice,
> rather than having to look at log output with the vendor's proprietary
> tool.
Maybe I'm peculiar but I always find it absolutely, totally jaw-dropping
when people use text *editors* to *look* at file content. Makes my toes
curl up and blood curdle.
Why on earth would you want to edit your system logs anyway?
On De{bi,vu}an derivatives, I'd use `pager`. On any other Unix-based
OS, I'd use `more` or `less`, preferably.
# On my own machines `lv` makes a fine `pager` for me. On the fly
# decompression and handling of many different encodings. So for me,
# it's just
#
# pager /var/log/syslog.2.gz
#
# without any `zmore` or `zcat` piping. There is still no zpager :-/
# but with `lv` I don't really need one.
Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9
Support Free Softwarehttps://my.fsf.org/donate
Join the Free Software Foundation https://my.fsf.org/join
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Viewing file content (was Re: system administration of non-systemd distros and releases)
> > What could possibly be easier than vim /var/log/messages, or
> > vi /var/log/messages, or emacs /var/log/messages, or
> > nano /var/log/messages? And notice with the old way, you have a choice,
> > rather than having to look at log output with the vendor's proprietary
> > tool.
>
> Maybe I'm peculiar but I always find it absolutely, totally jaw-dropping
> when people use text *editors* to *look* at file content. Makes my toes
> curl up and blood curdle.
>
> Why on earth would you want to edit your system logs anyway?
>
> On De{bi,vu}an derivatives, I'd use `pager`. On any other Unix-based
> OS, I'd use `more` or `less`, preferably.
I concur - the model ought to be that log files aren't writeable
in the conventional sense, but append only. For installations where
one worries about security this might even be enforced with chattr
at the filesystem level (ie not just convention).
Using a pager is also more efficient - pagers are simpler, faster and
don't risk accidentally modifying the file. Depending on
editor a harmless update can involve a rename() aka mv, in which case
subsequent log entries might be lost.
If (any of) you still prefer to use an editor, consider invoking it in
read-only mode. Eg "vim" can also be invoked as "view"
regards
marc
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Viewing file content (was Re: system administration of non-systemd distros and releases)
Personally, if I want to look at a file without editing it, if it's
small, I'll use view - which gives me the vi interface with the file in
read-only mode. It means I get the same interface and facilities that I
use when actually editing files, and it's easy to remember and (usually)
automatic. If I'm examining logs, I normally use less: handles big files
well, and (to coin a phrase) has more functionality than "more". It also
has the brilliant ctrl-f feature to show updates to the log in real-time
(like "tail -f" but with the advantage that the "tailing" mode can be
entered and exited without losing access to the file).
On Fri, 2021-11-26 at 18:40 +0900, Olaf Meeuwissen via Dng wrote:
> Hi,
>
> Steve Litt writes:
>
> > What could possibly be easier than vim /var/log/messages, or
> > vi /var/log/messages, or emacs /var/log/messages, or
> > nano /var/log/messages? And notice with the old way, you have a choice,
> > rather than having to look at log output with the vendor's proprietary
> > tool.
>
> Maybe I'm peculiar but I always find it absolutely, totally jaw-dropping
> when people use text *editors* to *look* at file content. Makes my toes
> curl up and blood curdle.
>
> Why on earth would you want to edit your system logs anyway?
>
> On De{bi,vu}an derivatives, I'd use `pager`. On any other Unix-based
> OS, I'd use `more` or `less`, preferably.
>
> # On my own machines `lv` makes a fine `pager` for me. On the fly
> # decompression and handling of many different encodings. So for me,
> # it's just
> #
> # pager /var/log/syslog.2.gz
> #
> # without any `zmore` or `zcat` piping. There is still no zpager :-/
> # but with `lv` I don't really need one.
>
> Hope this helps,
> --
> Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
> GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9
> Support Free Softwarehttps://my.fsf.org/donate
> Join the Free Software Foundation https://my.fsf.org/join
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Viewing file content (was Re: system administration of non-systemd distros and releases)
> On 26 Nov 2021, at 20:40, Olaf Meeuwissen via Dng wrote: > > # On my own machines `lv` makes a fine `pager` for me. On the fly > # decompression and handling of many different encodings. So for me, > # it's just > # > # pager /var/log/syslog.2.gz > # > # without any `zmore` or `zcat` piping. There is still no zpager :-/ > # but with `lv` I don't really need one. Does lv provide anything extra or different to enabling lesspipe.sh in bashrc? ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] system administration of non-systemd distros and releases
The trouble is that it's not just an OS for geeks - it's the OS on which the vast majority of the internet runs. If the sysadmins who maintain the servers which form the infrastructure and backbone of the internet were to get de-skilled, that would be a very big problem. (Although, I should say that I personally can't for a moment imagine that that would happen.) On Thu, 2021-11-25 at 19:50 +0100, Didier Kryn wrote: > For myself, I prefer Linux to remain an OS for geeks rather than try > to catch the market of clueless users, but the last has been, for > decades, the quest of Gnome, and now of Freedesktop. Systemd fits well > in the plot. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] system administration of non-systemd distros and releases
It's a bit like the charlatans and fake doctors in past centuries. They'd invent an illness, and then claim to have a remedy for it: https://en.wiktionary.org/wiki/marthambles On Thu, 2021-11-25 at 09:55 -0800, Syeed Ali wrote: > On Thu, 25 Nov 2021 10:35:13 -0500 > Steve Litt wrote: > > > I quote then-Redhat CTO Brian Stevens: "Red Hat's model works because > > of the complexity of the technology we work with." > > Create the problem, provide the solution. > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] What not to back up
On 24/11/2021 10:08, Olaf Meeuwissen via Dng wrote:
Hi Hendrik,
Hendrik Boom writes:
I'm setting up a new backup script that will do it all piecemeal so
that if a part of it fails, it can be retried without having to start
*everythng* over from scratch.
Which top-level filesystems should *not* be backed up.
To start with, I presumably shouldn't back up
/proc
/tmp
/dev (cause I'm using some version of *udev)
/mnt
ACK.
and I certainly should back up /var, /usr. /root, /bin,
/boot, /etc, /home, /lib, /lib64, /sbin
I wouldn't bother with /var/cache and /var/log but you're talking
top-level ;-)
... but if you run a nameserver you may well need:
/var/cache/bind
as that's where your zonefiles are ;-)
/boot is managed by installing kernel images and grub (using settings in
/etc/grub) so isn't all that important to include. At least on amd64.
But what about
/run
/srv
/sys
?
Both /run and /sys are tmpfs file systems. Not worth backing up.
However some admins put services in:
/srv
and some third-party suppliers of software place it in:
/opt
for example Sophos anti-virus.
Basically, you should only care about a subset of what lives below the
mount points listed by
df | grep ^/ | awk '{print $6}'
and make sure your backup command doesn't cross file system boundaries.
That should automatically exclude things like /dev, /proc, /run, /sys
and may (or may not) exclude /tmp (depending on installation choices).
As /mnt is meant for temporary mounts, that should be excluded too.
What are those even used for?
I would have pointed you to the FHS but as Lars pointed out already `man
7 hier` will tell.
Of course, if you don't use things like /srv and /opt, there's not much
of a cost to backing up the empty directories :-)
Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9
Support Free Softwarehttps://my.fsf.org/donate
Join the Free Software Foundation https://my.fsf.org/join
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Devuan 4.0 on Sophos firewall hardware
Just in case anyone is interested, I have had good success at installing Devuan 4.0 on to second hand Sophos firewall hardware (XG115 and XG125, Rev 3) to make light-weight firewalls and network appliances. You have to use a terminal program on the console port at 38400 to get access to the AMI bios, you can turn off the console port redirection and revert to the HDMI output (Rev 3 hardware) and then boot from a USB stick with 'netinst' and flatten the Sophos firmware on the 64Gb eMMC and install Devuan. The result is a fast quad core Intel Atom C3508 with four Intel I211 (XG115) or eight Intel 211/X553 gigabit Ethernet ports and an I210 SFP port (XG125). Processor Information Socket Designation: CPU0 Type: Central Processor Family: Pentium 4 Manufacturer: Intel(R) Corporation ID: F1 06 05 00 FF FB EB BF Signature: Type 0, Family 6, Model 95, Stepping 1 Flags: FPU (Floating-point unit on-chip) VME (Virtual mode extension) DE (Debugging extension) PSE (Page size extension) TSC (Time stamp counter) MSR (Model specific registers) PAE (Physical address extension) MCE (Machine check exception) CX8 (CMPXCHG8 instruction supported) APIC (On-chip APIC hardware supported) SEP (Fast system call) MTRR (Memory type range registers) PGE (Page global enable) MCA (Machine check architecture) CMOV (Conditional move instruction supported) PAT (Page attribute table) PSE-36 (36-bit page size extension) CLFSH (CLFLUSH instruction supported) DS (Debug store) ACPI (ACPI supported) MMX (MMX technology supported) FXSR (FXSAVE and FXSTOR instructions supported) SSE (Streaming SIMD extensions) SSE2 (Streaming SIMD extensions 2) SS (Self-snoop) HTT (Multi-threading) TM (Thermal monitor supported) PBE (Pending break enabled) Version: Intel(R) Atom(TM) CPU C3508 @ 1.60GHz Voltage: 1.6 V External Clock: 100 MHz Max Speed: 3800 MHz Current Speed: 1600 MHz Status: Populated, Enabled Upgrade: Socket LGA775 L1 Cache Handle: 0x002F L2 Cache Handle: 0x0030 L3 Cache Handle: Not Provided Serial Number: Not Specified Asset Tag: UNKNOWN Part Number: Not Specified Core Count: 4 Core Enabled: 4 Thread Count: 4 Characteristics: 64-bit capable Multi-Core Hardware Thread Execute Protection Enhanced Virtualization Power/Performance Control root@xg125:/home/mike/mycrypt# lspci 00:00.0 Host bridge: Intel Corporation Atom Processor C3000 Series System Agent (rev 11) 00:04.0 Host bridge: Intel Corporation Atom Processor C3000 Series Error Registers (rev 11) 00:05.0 Generic system peripheral [0807]: Intel Corporation Atom Processor C3000 Series Root Complex Event Collector (rev 11) 00:06.0 PCI bridge: Intel Corporation Atom Processor C3000 Series Integrated QAT Root Port (rev 11) 00:09.0 PCI bridge: Intel Corporation Atom Processor C3000 Series PCI Express Root Port #0 (rev 11) 00:0a.0 PCI bridge: Intel Corporation Atom Processor C3000 Series PCI Express Root Port #1 (rev 11) 00:0b.0 PCI bridge: Intel Corporation Atom Processor C3000 Series PCI Express Root Port #2 (rev 11) 00:0c.0 PCI bridge: Intel Corporation Atom Processor C3000 Series PCI Express Root Port #3 (rev 11) 00:0e.0 PCI bridge: Intel Corporation Atom Processor C3000 Series PCI Express Root Port #4 (rev 11) 00:0f.0 PCI bridge: Intel Corporation Atom Processor C3000 Series PCI Express Root Port #5 (rev 11) 00:10.0 PCI bridge: Intel Corporation Atom Processor C3000 Series PCI Express Root Port #6 (rev 11) 00:11.0 PCI bridge: Intel Corporation Atom Processor C3000 Series PCI Express Root Port #7 (rev 11) 00:12.0 System peripheral: Intel Corporation Atom Processor C3000 Series SMBus Contoller - Host (rev 11) 00:13.0 SATA controller: Intel Corporation Atom Processor C3000 Series SATA Controller 0 (rev 11) 00:15.0 USB controller: Intel Corporation Atom Processor C3000 Series USB 3.0 xHCI Controller (rev 11) 00:16.0 PCI bridge: Intel Corporation Atom Processor C3000 Series Integrated LAN Root Port #0 (rev 11) 00:17.0 PCI bridge: Intel Corporation Atom Processor C3000 Series Integrated LAN Root Port #1 (rev 11) 00:18.0 Communication controller: Intel Corporation Atom Processor C3000 Series ME HECI 1 (rev 11) 00:1f.0 ISA bridge: Intel Corporation Atom Processor C3000 Series LPC or eSPI (rev 11) 00:1f.2 Memory controller: Intel Corporation Atom Pro
Re: [DNG] system administration of non-systemd distros and releases
On 11/25/21 17:11, Steve Litt wrote: [snip] Imagine if they made a car with the engine compartment welded shut, and gave you a little cockpit in the passenger compartment to control a robot inside the engine compartment that would do maintenance and repairs. That's not too far off from new cars as they are today. They are lousy with sensors and everything is tied directly or indirectly to the dealer, either through proprietary programs + proprietary protocols or service contracts or both. You can't change your own oil though I think changing the wiper blades on your own is still allowed. And by "you" I mean the ostensible owner or an independent repair shop. The cars are not recognized as computer systems, but as Cory Doctorow pointed out they are a computer you put your body into. I have only a weak grasp of the situation, having kept my head in the sand as long as I could, but I think two non-excusive approaches to solving the car software / protocol problem might be through software liability (as outlined by Geer and Kamp [1]) and through the ongoing attempts to restore the "right to repair" as led by Rossmann [2], in particular the latter which is picking momentum in regards to heavy farm equipment. /Lars [1] Transcript, "Cybersecurity as Realpolitik", Dan Geer: http://geer.tinho.net/geer.blackhat.6viii14.txt Video: https://youtu.be/nT-TGvYOBpI "The Software Industry IS STILL the Problem: The time is (also) way overdue for IT professional liability" Poul-Henning Kamp (2021) https://dl.acm.org/doi/10.1145/3487019.3489045 "The Software Industry IS the Problem: The time has come for software liability laws." Poul-Henning Kamp (2011) https://queue.acm.org/detail.cfm?id=2030258 [2] https://www.fighttorepair.org/ ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan 4.0 on Sophos firewall hardware
On Fri, 26 Nov 2021 13:24:26 + Mike Tubby wrote: > Just in case anyone is interested, I have had good success at installing > Devuan 4.0 on to second hand Sophos firewall hardware (XG115 and XG125, > Rev 3) to make light-weight firewalls and network appliances. Hi, I have it running on a Sophos UTM 425 appliance (inclusive working LCD display), on a Lanner FW8759 (inclusive working LCD display) and on self built router with a Jetway JNF592-Q170 motherboard. I'm very happy about all of them. Ciao, Tito > You have to use a terminal program on the console port at 38400 to get > access to the AMI bios, you can turn off the console port redirection > and revert to the HDMI output (Rev 3 hardware) and then boot from a USB > stick with 'netinst' and flatten the Sophos firmware on the 64Gb eMMC > and install Devuan. > > The result is a fast quad core Intel Atom C3508 with four Intel I211 > (XG115) or eight Intel 211/X553 gigabit Ethernet ports and an I210 SFP > port (XG125). > > Processor Information > Socket Designation: CPU0 > Type: Central Processor > Family: Pentium 4 > Manufacturer: Intel(R) Corporation > ID: F1 06 05 00 FF FB EB BF > Signature: Type 0, Family 6, Model 95, Stepping 1 > Flags: > FPU (Floating-point unit on-chip) > VME (Virtual mode extension) > DE (Debugging extension) > PSE (Page size extension) > TSC (Time stamp counter) > MSR (Model specific registers) > PAE (Physical address extension) > MCE (Machine check exception) > CX8 (CMPXCHG8 instruction supported) > APIC (On-chip APIC hardware supported) > SEP (Fast system call) > MTRR (Memory type range registers) > PGE (Page global enable) > MCA (Machine check architecture) > CMOV (Conditional move instruction supported) > PAT (Page attribute table) > PSE-36 (36-bit page size extension) > CLFSH (CLFLUSH instruction supported) > DS (Debug store) > ACPI (ACPI supported) > MMX (MMX technology supported) > FXSR (FXSAVE and FXSTOR instructions supported) > SSE (Streaming SIMD extensions) > SSE2 (Streaming SIMD extensions 2) > SS (Self-snoop) > HTT (Multi-threading) > TM (Thermal monitor supported) > PBE (Pending break enabled) > Version: Intel(R) Atom(TM) CPU C3508 @ 1.60GHz > Voltage: 1.6 V > External Clock: 100 MHz > Max Speed: 3800 MHz > Current Speed: 1600 MHz > Status: Populated, Enabled > Upgrade: Socket LGA775 > L1 Cache Handle: 0x002F > L2 Cache Handle: 0x0030 > L3 Cache Handle: Not Provided > Serial Number: Not Specified > Asset Tag: UNKNOWN > Part Number: Not Specified > Core Count: 4 > Core Enabled: 4 > Thread Count: 4 > Characteristics: > 64-bit capable > Multi-Core > Hardware Thread > Execute Protection > Enhanced Virtualization > Power/Performance Control > > root@xg125:/home/mike/mycrypt# lspci > 00:00.0 Host bridge: Intel Corporation Atom Processor C3000 Series > System Agent (rev 11) > 00:04.0 Host bridge: Intel Corporation Atom Processor C3000 Series Error > Registers (rev 11) > 00:05.0 Generic system peripheral [0807]: Intel Corporation Atom > Processor C3000 Series Root Complex Event Collector (rev 11) > 00:06.0 PCI bridge: Intel Corporation Atom Processor C3000 Series > Integrated QAT Root Port (rev 11) > 00:09.0 PCI bridge: Intel Corporation Atom Processor C3000 Series PCI > Express Root Port #0 (rev 11) > 00:0a.0 PCI bridge: Intel Corporation Atom Processor C3000 Series PCI > Express Root Port #1 (rev 11) > 00:0b.0 PCI bridge: Intel Corporation Atom Processor C3000 Series PCI > Express Root Port #2 (rev 11) > 00:0c.0 PCI bridge: Intel Corporation Atom Processor C3000 Series PCI > Express Root Port #3 (rev 11) > 00:0e.0 PCI bridge: Intel Corporation Atom Processor C3000 Series PCI > Express Root Port #4 (rev 11) > 00:0f.0 PCI bridge: Intel Corporation Atom Processor C3000 Series PCI > Express Root Port #5 (rev 11) > 00:10.0 PCI bridge: Intel Corporation Atom Processor C3000 Series PCI > Express Root Port #6 (rev 11) > 00:11.0 PCI bridge: Intel Corporation Atom Processor C3000 Series PCI > Express Root Port #7 (rev 11) > 00:12.0 System peripheral: Intel Corporation Atom Processor C3000 Series > SMBus Contoller - Host (rev 11) > 00:13.0 SATA controller: Intel Corporation Atom Processor C3000 Series > SATA Controller 0
Re: [DNG] system administration of non-systemd distros and releases
On 2021-11-26 05:08, Peter Duffy wrote: It's a bit like the charlatans and fake doctors in past centuries. They'd invent an illness, and then claim to have a remedy for it: https://en.wiktionary.org/wiki/marthambles LOL! Isn't that exactly what big pharma is still doing with direct marketing to consumers of their latest "cure" for a newly discovered "disease"? golinux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] system administration of non-systemd distros and releases
On Thu, 2021-11-25 at 18:11 +, Simon wrote: > In the early days of motoring, you had a lot to learn and cars were > non-trivial to drive and to keep going - to the extent that many users > employed someone to do the driving for them. Roll forward through the > years, and cars have got more and more complicated, but also easier > and easier to operate and more and more reliable. At one time I used > to carry a basic tool kit all the time, now I don’t as a) the car is > quite unlikely to break down and b) there’s probably nothing I can do > anyway. > But now, anyone with basic skills can make a car get them from A to B, > in relative comfort, and typically without drama. Very true. I used to have a Morris Minor, and did virtually all the maintenance myself (well, anything which didn't involve getting the engine out of the car). But in the case of my current car, I'd be scared to touch anything but the most trivial problems, in case I broke something and turned a problem into a disaster: it's all just so much more complex and interconnected. Maybe the problem with the car analogy is that it's only really applicable to end-user computers - desktops and laptops. For servers, the analogy would need to be extended to buses and HGVs. In those cases, where many people rely on the availability and punctuality of the vehicles, the drivers and pilots don't fix the problems themselves, and also don't go back to the manufacturers to get problems fixed: the companies which run the vehicles have teams of engineers who can strip the thing down to components and reassemble it. > > By analogy, back in the days when “computers” really only meant the > likes of big IBM iron, few could “drive” it - to the point that most > business people employed people to do the driving and they simply said > where they want to go (e.g. get some numbers out on a printed report). > Now, for many, they do their own driving using BI tools, dashboards, > and the like. I think that in the "big iron" days, it was even more extreme: companies just went to IBM etc. and said they wanted a computer. IBM sent in their team, did systems analysis on the company's existing paper system, then spec'd a computer to do the job. All the company did was agree to IBM's price, take delivery of the beast, and then pay IBM even more dosh to teach them how to use it. When people found that they could now buy something off the shelf, and it would (more or less) do what they needed, it was a revelation. To say nothing of a big problem for IBM. > > > But if systemd makes it more difficult to solve problems, and makes > the > > system more unreliable, then the customers aren't even getting what > they > > paid for before systemd was introduced. The problem is obviously > proving > > whether or not systemd really does make a system more > > unreliable/undiagnosable. > > Well provided nothing goes wrong, clearly SystemD is easier to use for > an admin without a clue. Clearly writing a unit file to start > something is so much easier than having to learn how to write in Bash. > I think that much is hard to disagree with. > And if the tools make looking at a journal file easier, (I’ve no > idea), then that bit is also true. > > So in some ways it’s a step along the road of making things easier for > the general user, or in this case, the power user or novice admin. So > yes, the user does get what they are asking for - but the downside is > that when it breaks, it’s harder to fix. Is it easier to use systemd? If someone's clueless, then they're probably not going to be doing much system administration anyway, and if something breaks, they're probably going to be picking up the phone and whining to their mate who happens to be a sysadmin. In most cases, anyone using linux who has any interest at all in the system is actively encouraged to at least dip their toe into bash shellscripting - simply because it's there, useful, and potentially interesting. It's always seemed to me that a basic level of shellscript skill is all that's required to craft init scripts: there are always plenty of examples lying around; there are probably web sites devoted to writing them. The great thing about a shell-based init script is the infinite flexibility; also the knowledge that if I've written it myself, I know what it's doing and if it goes wrong, I'll hopefully have some clue as to what has gone wrong. Writing a systemd unit file - I admit I've never tried it (yet) - looks to be a daunting prospect. And even given the vast number of options, it's a straitjacket compared with bash facilities. > > > > I've wondered for a long time if it would be independently possible > to > > make systemd optional. > > I think you found that the answer is no. > IIF, and that’s a massive IF, SystemD had only been “another init > system” then yes. But there are so many dependencies where devs of all > sorts of software have to make an either/or choice of whether to > support SystemD
Re: [DNG] system administration of non-systemd distros and releases
Le 26/11/2021 à 12:05, Peter Duffy a écrit : > The trouble is that it's not just an OS for geeks - it's the OS on which > the vast majority of the internet runs. > > If the sysadmins who maintain the servers which form the infrastructure > and backbone of the internet were to get de-skilled, that would be a > very big problem. (Although, I should say that I personally can't for a > moment imagine that that would happen.) > > On Thu, 2021-11-25 at 19:50 +0100, Didier Kryn wrote: > >> For myself, I prefer Linux to remain an OS for geeks rather than try >> to catch the market of clueless users, but the last has been, for >> decades, the quest of Gnome, and now of Freedesktop. Systemd fits well >> in the plot. Sorry, it wasn't clear but I include professionals amongst geeks. I think systemd is meant for the clueless user who is the admin of his own computer. Or maybe there will advent a new class of clueless sysadmins... -- Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] system administration of non-systemd distros and releases
On 26-11-2021 17:27, goli...@devuan.org wrote: On 2021-11-26 05:08, Peter Duffy wrote: It's a bit like the charlatans and fake doctors in past centuries. They'd invent an illness, and then claim to have a remedy for it: https://en.wiktionary.org/wiki/marthambles LOL! Isn't that exactly what big pharma is still doing with direct marketing to consumers of their latest "cure" for a newly discovered "disease"? golinux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng Well, big pharma does do some research and sometimes come with new and useful medication. But it is true that they spend more on marketing than on research. Grtz Nick ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] system administration of non-systemd distros and releases
On 11/26/21 1:57 PM, d...@d404.nl wrote: On 26-11-2021 17:27, goli...@devuan.org wrote: On 2021-11-26 05:08, Peter Duffy wrote: It's a bit like the charlatans and fake doctors in past centuries. They'd invent an illness, and then claim to have a remedy for it: https://en.wiktionary.org/wiki/marthambles LOL! Isn't that exactly what big pharma is still doing with direct marketing to consumers of their latest "cure" for a newly discovered "disease"? golinux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng Well, big pharma does do some research and sometimes come with new and useful medication. But it is true that they spend more on marketing than on research. Grtz Nick ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng I am not trying to create problems of any type. I would honestly like the source of the claim that big pharma spends more on marketing than on research, before I repeat it, and am left without a defense. Ken ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] system administration of non-systemd distros and releases
Steve Litt wrote: >>> I've wondered for a long time if it would be independently possible >>> to make systemd optional. >> >> I think you found that the answer is no. > > I think you might be pleasantly surprised. In, to use the term loosely, > "discussions" with systemd's biggest fanboy whose initials weren't LP, > I found out, according to him, that the only two systemd services that > can't be removed are PID1 and journald. If the fanboy is correct, then > you can install the runit process supervisor (not the whole init > system), and one by one, disable systemd's handling of the other > services, so all systemd does is launch runit and act as a logging > mechanism. I’ll admit that I’ve not really followed the subject all that much, but it’s my understanding that you can’t just replace a couple of services. It’s not that you can’t replace a SystemD service with something else, but the way SystemD has been extending it’s tentacles into all sorts of stuff that wasn't broken (and replacing it with broken alternatives - c.f. ntp). I may be completely wrong, but it was my impression that they’ve been so trigger happy replacing established APIs with “better because it’s new” APIs that a lot of packages won’t work OFF THE SHELF without SystemD running and servicing those new APIs. So I think it comes down to whether the devs for the package you want to run took the time to encode multiple “if systemd then do X else do Y” (or ifdef buildforsystemd then do X else do Y) stuff in their code. At some point, if you are writing with an eye on distros that all run SystemD then someone could be tempted to just write “do X” - and then that package won’t work if the API for X isn’t present. And of course, at some point (if there isn’t already) then it’s likely that SystemD will introduce something whose semantics are different - so it’s not just a case of “call API X or call API Y”, but case of do a bunch of stuff one way or do it a different way. So the statement you’ve quoted may technically be correct, but may also be “somewhat misleading”. Lars Noodén via Dng wrote: > That's not too far off from new cars as they are today. They are lousy > with sensors and everything is tied directly or indirectly to the > dealer, either through proprietary programs + proprietary protocols or > service contracts or both. You can't change your own oil though I think > changing the wiper blades on your own is still allowed. And by "you" I > mean the ostensible owner or an independent repair shop. > > The cars are not recognized as computer systems, but as Cory Doctorow > pointed out they are a computer you put your body into. I have only a > weak grasp of the situation, having kept my head in the sand as long as > I could, but I think two non-excusive approaches to solving the car > software / protocol problem might be through software liability (as > outlined by Geer and Kamp [1]) and through the ongoing attempts to > restore the "right to repair" as led by Rossmann [2], in particular the > latter which is picking momentum in regards to heavy farm equipment. I can’t speak for commercial vehicles or agricultural machinery, but for cars things took a positive turn in the EU many years ago. At one point, car manufacturers were heading down the road towards “only a franchised dealer can do X, Y, Z” and independents would be locked out - due to lack of third party diagnostics etc as we’re seeing with (for example) John Deere. The first I recall was BMW where only franchised dealers were allowed access to the unit needed to reset the maintenance light - but as I recall, it wasn’t long before the protocol was reverse engineered and third parties started selling the ability to non-franchised dealers. The car manufacturers rolled out all the familiar reasons why only franchised dealers should be allowed to do anything - the “think about idiots fitting substandard parts” one being the biggest. But the rules were changed, the car market was stripped of it’s exemption from certain competition laws, and suddenly it was illegal to have franchised dealers with defined geographic areas, it was illegal to tie franchised dealers to only dealing with the one manufacturer, and the biggest benefit of all was that it was illegal to withhold maintenance and diagnostics information from non-franchised dealers. I can’t remember whether it was part of this or a separate rule change, but at some point it was made a legal requirement to implement a standardised diagnostics port - and the EOBD port was born. So I guess we have it easy over here, and I hope things change in that way for you over the other side of the pond. Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] system administration of non-systemd distros and releases
Anno domini 2021 Fri, 26 Nov 15:33:11 -0500 Ken Dibble scripsit: > On 11/26/21 1:57 PM, d...@d404.nl wrote: > > On 26-11-2021 17:27, goli...@devuan.org wrote: > >> On 2021-11-26 05:08, Peter Duffy wrote: > >>> It's a bit like the charlatans and fake doctors in past centuries. > >>> They'd invent an illness, and then claim to have a remedy for it: > >>> > >>> https://en.wiktionary.org/wiki/marthambles > >>> > >>> > >> > >> LOL! Isn't that exactly what big pharma is still doing with direct > >> marketing to consumers of their latest "cure" for a newly discovered > >> "disease"? > >> > >> golinux > >> ___ > >> Dng mailing list > >> Dng@lists.dyne.org > >> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > > > > Well, big pharma does do some research and sometimes come with new and > > useful medication. But it is true that they spend more on marketing > > than on research. > > > > Grtz > > > > Nick > > > > ___ > > Dng mailing list > > Dng@lists.dyne.org > > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > > I am not trying to create problems of any type. I would honestly like > the source of the claim that big pharma spends more on marketing than on > research, before I repeat it, and am left without a defense. 5% R&D, 45% Marketing, 50% profit - at least these were the last published numbers. Sorry, I just have a source in german: https://www.amazon.de/Lizenz-Pl%C3%BCndern-multilaterale-Abkommen-Investitionen/dp/3434530177 This book ist not the newest, but it has valid numbers. And both authors have quite a name :) Nik > > > Ken > > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > -- Please do not email me anything that you are not comfortable also sharing with the NSA, CIA ... ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] system administration of non-systemd distros and releases
On 26-11-2021 21:53, Dr. Nikolaus Klepp via Dng wrote: Anno domini 2021 Fri, 26 Nov 15:33:11 -0500 Ken Dibble scripsit: On 11/26/21 1:57 PM, d...@d404.nl wrote: On 26-11-2021 17:27, goli...@devuan.org wrote: On 2021-11-26 05:08, Peter Duffy wrote: It's a bit like the charlatans and fake doctors in past centuries. They'd invent an illness, and then claim to have a remedy for it: https://en.wiktionary.org/wiki/marthambles LOL! Isn't that exactly what big pharma is still doing with direct marketing to consumers of their latest "cure" for a newly discovered "disease"? golinux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng Well, big pharma does do some research and sometimes come with new and useful medication. But it is true that they spend more on marketing than on research. Grtz Nick ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng I am not trying to create problems of any type. I would honestly like the source of the claim that big pharma spends more on marketing than on research, before I repeat it, and am left without a defense. 5% R&D, 45% Marketing, 50% profit - at least these were the last published numbers. Sorry, I just have a source in german: https://www.amazon.de/Lizenz-Pl%C3%BCndern-multilaterale-Abkommen-Investitionen/dp/3434530177 This book ist not the newest, but it has valid numbers. And both authors have quite a name :) Nik Ken ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng This is reasonable recent https://www.pharmacychecker.com/askpc/pharma-marketing-research-development/ Grtz Nick ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Viewing file content (was Re: system administration of non-systemd distros and releases)
Olaf Meeuwissen said on Fri, 26 Nov 2021 18:40:37 +0900 >Hi, > >Steve Litt writes: > >> What could possibly be easier than vim /var/log/messages, or >> vi /var/log/messages, or emacs /var/log/messages, or >> nano /var/log/messages? And notice with the old way, you have a >> choice, rather than having to look at log output with the vendor's >> proprietary tool. > >Maybe I'm peculiar but I always find it absolutely, totally >jaw-dropping when people use text *editors* to *look* at file content. > Makes my toes curl up and blood curdle. You're right. Use less or some other *viewer*. 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] system administration of non-systemd distros and releases
Peter Duffy said on Fri, 26 Nov 2021 11:08:27 + >It's a bit like the charlatans and fake doctors in past centuries. >They'd invent an illness, and then claim to have a remedy for it: > >https://en.wiktionary.org/wiki/marthambles Or, more recently, http://bentcarrot.com. It's bent? Oh, the horror! Your PID1 doesn't support multiseat? Oh, the horror! 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 not to back up
Mike Tubby said on Fri, 26 Nov 2021 13:07:36 + > >... but if you run a nameserver you may well need: > > /var/cache/bind > >as that's where your zonefiles are ;-) Thanks for reminding me again one of the reasons I don't use bind. Who in their right mind would put zone files in a cache directory? Sounds like something Poetterpinhead would do. I'm an unbound/nsd guy myself. Before that I was a djbdns guy. Both put config in config directories. 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 not to back up
Or, tell bind to place the zone files where they originally were, in
/etc/bind/zones or something.
The change was made about 10 years ago as a "security feature" and is
mainly used for running bind in a jail, so if it gets hacked, they can't
mess up the rest of the server. I remember when Debian went that way and
it confused me quite a bit.
Of course, if you have a dedicated server only for BIND, that reason
goes away.
So, simply edit /etc/bind/* and change /var/lib/bind to whatever you
want. For the most part, I just store them in /etc/bind/SEC or
/etc/bind/ZONES or something. BIND doesn't care; it is the distro people
doing that.
Rod
On 11/26/21 7:07 AM, Mike Tubby wrote:
>
>
> On 24/11/2021 10:08, Olaf Meeuwissen via Dng wrote:
>> Hi Hendrik,
>>
>> Hendrik Boom writes:
>>
>>> I'm setting up a new backup script that will do it all piecemeal so
>>> that if a part of it fails, it can be retried without having to start
>>> *everythng* over from scratch.
>>>
>>> Which top-level filesystems should *not* be backed up.
>>>
>>> To start with, I presumably shouldn't back up
>>>
>>> /proc
>>> /tmp
>>> /dev (cause I'm using some version of *udev)
>>> /mnt
>> ACK.
>>
>>> and I certainly should back up /var, /usr. /root, /bin,
>>> /boot, /etc, /home, /lib, /lib64, /sbin
>> I wouldn't bother with /var/cache and /var/log but you're talking
>> top-level ;-)
>
> ... but if you run a nameserver you may well need:
>
> /var/cache/bind
>
> as that's where your zonefiles are ;-)
>
>
>> /boot is managed by installing kernel images and grub (using settings in
>> /etc/grub) so isn't all that important to include. At least on amd64.
>>
>>> But what about
>>>
>>> /run
>>> /srv
>>> /sys
>>> ?
>> Both /run and /sys are tmpfs file systems. Not worth backing up.
>
>
> However some admins put services in:
>
> /srv
>
> and some third-party suppliers of software place it in:
>
> /opt
>
> for example Sophos anti-virus.
>
>> Basically, you should only care about a subset of what lives below the
>> mount points listed by
>>
>> df | grep ^/ | awk '{print $6}'
>>
>> and make sure your backup command doesn't cross file system boundaries.
>> That should automatically exclude things like /dev, /proc, /run, /sys
>> and may (or may not) exclude /tmp (depending on installation choices).
>> As /mnt is meant for temporary mounts, that should be excluded too.
>>
>>> What are those even used for?
>> I would have pointed you to the FHS but as Lars pointed out already `man
>> 7 hier` will tell.
>>
>> Of course, if you don't use things like /srv and /opt, there's not much
>> of a cost to backing up the empty directories :-)
>>
>> Hope this helps,
>> --
>> Olaf Meeuwissen, LPIC-2 FSF Associate Member since 2004-01-27
>> GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9
>> Support Free Software https://my.fsf.org/donate
>> Join the Free Software Foundation https://my.fsf.org/join
>> ___
>> Dng mailing list
>> Dng@lists.dyne.org
>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
--
Rod Rodolico
Daily Data, Inc.
POB 140465
Dallas TX 75214-0465 US
https://dailydata.net
214.827.2170 ext 100
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Viewing file content (was Re: system administration of non-systemd distros and releases)
Hi, wirelessduck--- via Dng writes: >> On 26 Nov 2021, at 20:40, Olaf Meeuwissen via Dng wrote: >> >> # On my own machines `lv` makes a fine `pager` for me. On the fly >> # decompression and handling of many different encodings. So for me, >> # it's just >> # >> # pager /var/log/syslog.2.gz >> # >> # without any `zmore` or `zcat` piping. There is still no zpager :-/ >> # but with `lv` I don't really need one. > > Does lv provide anything extra or different to enabling lesspipe.sh in bashrc? The main reason for me to use lv was a need to view text files encoded in one of Shift-JIS, EUC-JP or UTF-8. With lv, most of the time it guesses the encoding right and if not you can loop through a bunch of supported encodings with `t`. # I've also had to deal with files with mixed encodings :-0, part # Shift-JIS, part ISO-8859-* and sometimes even a bit in one of the # Chinese encodings. Being able to toggle encoding for the current # "page" on the fly makes it at least possible to see what's in the # file. Looking at the lesspipe manual page[1] (don't have less installed ;-), it seems that it doesn't support on-the-fly encoding switching but as far as dealing with compressed files, I guess there is no or not much difference. [1]: https://manpages.debian.org/bullseye/less/lesspipe.1.en.html Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] system administration of non-systemd distros and releases
On 11/26/21 3:59 PM, d...@d404.nl wrote: On 26-11-2021 21:53, Dr. Nikolaus Klepp via Dng wrote: Anno domini 2021 Fri, 26 Nov 15:33:11 -0500 Ken Dibble scripsit: On 11/26/21 1:57 PM, d...@d404.nl wrote: On 26-11-2021 17:27, goli...@devuan.org wrote: On 2021-11-26 05:08, Peter Duffy wrote: It's a bit like the charlatans and fake doctors in past centuries. They'd invent an illness, and then claim to have a remedy for it: https://en.wiktionary.org/wiki/marthambles LOL! Isn't that exactly what big pharma is still doing with direct marketing to consumers of their latest "cure" for a newly discovered "disease"? golinux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng Well, big pharma does do some research and sometimes come with new and useful medication. But it is true that they spend more on marketing than on research. Grtz Nick ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng I am not trying to create problems of any type. I would honestly like the source of the claim that big pharma spends more on marketing than on research, before I repeat it, and am left without a defense. 5% R&D, 45% Marketing, 50% profit - at least these were the last published numbers. Sorry, I just have a source in german: https://www.amazon.de/Lizenz-Pl%C3%BCndern-multilaterale-Abkommen-Investitionen/dp/3434530177 This book ist not the newest, but it has valid numbers. And both authors have quite a name :) Nik Ken ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng This is reasonable recent https://www.pharmacychecker.com/askpc/pharma-marketing-research-development/ Grtz Nick ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng Thank You. That is both sad and scary. Ken ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] system administration of non-systemd distros and releases
On Fri, 26 Nov 2021 20:29:07 -0600 Rod Rodolico wrote: > For a really nice Linux based router distro, look at IPFire > (https://www.ipfire.org/). They suffer from being too small, so they > don't have a lot of people testing, so updates sometimes have issues. > But, it is very secure, and has good support on the mailing lists. > > I use opnSense (FreeBSD, https://opnsense.org/), but only because I'm a > control freak and want to do every little thing myself. But, when I have > a client who wants to manage their own firewall/router, I set up IPFire > for them. > > A long time ago, I built a couple of firewalls from scratch (based on > Debian). I learned my lesson and figured out very fast it was better to > find a project like IPFire/opnSense and just support them :) > > Rod Hi. I've tried all of them and every single one had something I didn't like or some glitches or the interesting stuff was paywalled. In the end I went for the DIY route which has lots of advantages: 1) you learn a lot while setting it up 2) you get exactly what you want 3) you get timely security updates 4) you get rid of image based updates 5) as long as debian/devuan exists you are good to go, the only time limit is the life of your hardware 6) you can stick with x86 boards and avoid all soc's and exotic arch boards that are abandoned the same moment you buy them 7) you get lots of cards an spare parts to play with and repair and enhance your router Ciao, Tito > > On 11/22/21 7:08 AM, tito via Dng wrote: > > On Mon, 22 Nov 2021 04:41:23 -0500 > > Steve Litt wrote: > > > >> steph.tougard said on Sun, 21 Nov 2021 04:19:36 + > >> > >> > >>> My Devuan is behind an OpenBSD. The OpenBSD has no software installed, > >>> it's a pure system as release by the OpenBSD team, the code base is > >>> small, strongly audited by a very small and known team. It can be > >>> considered safe, at least safer. Much safer than any Debian based > >>> distribution. My network configuration is so safe that I could safely > >>> store unencrypted Bitcoin private keys on an unpatched Windows 98 > >>> without any risk if I wish. > >> > >> We've all built OpenBSD/pf firewall/routers. You didn't think of > > > > > > .and linux routers. > > > > Ciao, > > Tito > > > >> nothing new --- we all know what a good firewall BSD/pf makes. That > >> doesn't preclude our using Linux on the LAN behind that firewall. > >> Like you do with Devuan. > >> > >> Why are you so angry? > >> > >> 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 > > > > ___ > > Dng mailing list > > Dng@lists.dyne.org > > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > > > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
