Re: [DNG] Configuring ethernet port for IPv6

[Simon Hobson]

Curtis Maurand  wrote:

> I think this is all great right up until you need a fixed address for 
> something like a mail server or a web server.

That is no more of a problem with IPv6 as it is with IPv4 - if you have a “poor 
quality” ISP that doesn’t do fixed addresses then you have a problem with 
anything that needs a fixed(dish) IP.

> So far, I've found IPV6 to be unreliable.

In what way ?
I’m not currently running IPv6 at home as I’ve not got round to reconfiguring 
the network to use my own (pre-systemd Debian, Linux VM) router, and the ISP 
supplied router doesn’t have the option to forward (IIRC) GRE needed to make my 
HE tunnel work.
But in the past when I have had IPv6 running, it’s worked fine. I didn’t run my 
email over IPv6 for the simple reason that at the time, there was one element 
of my software stack that didn’t fully cope with it. Again, not found time to 
update everything - I believe that one issue was fixed a while ago.

Going back probably around 10 years, I enabled IPv6 on our office network and 
waited to see if anyone noticed - no-one did, and we didn’t start experiencing 
new problems.

Simon

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] meta: list

[Simon Hobson]

Marjorie Roome via Dng  wrote:

> I configure strict postfix rules that incoming mail should have a
> reverse DNS.

Ah, we’re talking two different checks. I too reject connections if there’s no 
reverse DNS, but ideally that reverse DNS should forward resolve to a list (one 
or more IPs) containing the IP of the connecting device. It’s this latter bit 
that people seem too incapable of getting right.

But while rejecting “no reverse DNS” does block a lot, there is a lot of spam 
that comes from addresses that have generic reverse DNS entries - many ISPs 
have reverse DNS setup for their customer IP ranges along the lines of 
a-b-c-d.dynamic.ispname.net.

I find grey-listing to be by far the most effective spam blocker.


Simon
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] meta: list

[Simon Hobson]

declassed art via Dng  wrote:

> I do have an unconfigured PTR for a couple of reasons, one of those is lack 
> of static IP for now.

I figured out quite quickly that checking reverse DNS is a waste of time - too 
many systems, even those run by professional network/server engineers, are just 
badly configured.



Gregory Nowak via Dng  wrote:

> I have toyed more than once with the question of what would happen if
> a group of us running our own mail exchanges made the choice to
> reject mail from gmail.com with a 550? If a few of us did it, we might
> miss mail we maybe wanted to get. If a bunch of us did it, then a
> bunch of gmail users would complain to google. My guess is google's
> response would be "this is a free service; if it doesn't work for you,
> then don't use it.”

No, I’ll tell you what Google’s response will be :
“Our system is working fine, the other system is broken”.
Don’t forget that this is a company that is quite happy to simply change the 
rules on the basis that it’s big enough that the rest of the world will adapt. 
Look at the history of stuff they’ve “just changed” because it suits them. 
Sticking with email, they were one of the first to implement SPF fully knowing 
that it would break most mailing lists and mail forwarders around the world - 
and so most mailing lists around the world had to update software & change 
setups to suit Google’s* new set of “how email is to work” rules. I know, I had 
a customer facing mail server** and mailing list server.

* OK, they weren’t the only ones, but they were one of the first.

In the network world, Android devices don’t work on managed networks using 
DHCPv6 for address assignment. For idealogical reasons, they don’t support 
DHCPv6 and even actively block third party support (by pressuring chipset 
manufacturers to block the packets in the hardware). I could be flippant and 
suggest it’s because they see it as their job to snoop on people and using DHCP 
allows network admins to do that, but it’s mostly because they are interested 
only in mobile applications and refuse to consider the needs of any other 
environment (even where it’s a legal requirement).

In the web world they are pushing for “SSL or it doesn’t exist” despite the 
fact that it does actually cost money** to add SSL and there are situations 
(such as supporting older hardware) where there is no SSL and never will be.
And of course, there’s the shenanigans with QUIK and DoH ...

So basically, Google’s attitude is that if some other system doesn’t work with 
their offering - then it’s the other system that’s broken. And they are big 
enough that they can get away with that, especially when they are able to tell 
users who complain that that’s the case.

** When SPF started getting applied, clients started seeing problems.
Ideally we’d have them set up an account in their mail client to get mail from 
our server using IMAP, but many customers would refuse to do that - “I want my 
mail in my inbox”. Trying to explain why that’s not a good idea is an exercise 
in futility. So once their ISP is checking SFP, they no longer get any emails 
from sources setting SPF - and it’s our fault that the client insists on doing 
the broken way.
Instead, they’d say it’s because out mail server is faulty - because that’s 
what their ISP (usually using an ISP mail account) told them and apparently the 
hell desks at the big ISPs are more honest that a small IT services company 
where they can be on first name terms with the staff.


Simon


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Microsoft: Really?

[Simon Hobson]

Mark Rousell  wrote:

> As I see it there are only two USPs for a service like this:
> 
> (1) It's accessible for anywhere you have Internet access and a computing 
> device.
> 
> (2) It is (I presume) backed up so you don't need to run your own backups... 
> well, in theory. In practice that should not be relied upon but people 
> definitely will give up doing their own backups due to systems like this.

You missed what is possibly the most important for many businesses :

(3) It's able to be bought as Opex rather than Capex.

Put another way, someone, somewhere, in the organisation can buy this on their 
expenses and cut out the IT department. They don't need to create a business 
case and go through an approvals process to spend on a capital asset - it just 
hides away in the operating budget for the department.
That in part is behind the rapid rise of a number of "something as a service" 
offerings - they can be hidden in departmental operating budgets instead of 
having to go and get capital approval, and allowing the IT dept to veto it.

So some middle manager somewhere who's got a crappy old PC can get themselves a 
nice juicy one in the cloud as long as they can cover the cost in their 
expenses. The fact that it ends up costing the company more than if they 
actually bought him a better one is besides the point - he's presumably doing 
this because they asked for a better PC and that request was turned down.

Simon

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Missing syslog

[Simon Hobson]

Hendrik Boom  wrote:

> I did a ls -l on syslog*
> 
> april:~# ls -l /var/log/syslog* 
> -rw-r- 1 root adm  734459 May 17  2013 /var/log/syslog
> -rw-r- 1 root adm 1197017 May 17  2013 /var/log/syslog.0
> -rw-r- 1 root adm   79876 May 13  2013 /var/log/syslog.1.gz
> -rw-r- 1 root adm  127547 May 12  2013 /var/log/syslog.2.gz
> -rw-r- 1 root adm   51821 May 10  2013 /var/log/syslog.3.gz
> -rw-r- 1 root adm   44679 May  9  2013 /var/log/syslog.4.gz
> -rw-r- 1 root adm   46240 May  8  2013 /var/log/syslog.5.gz
> -rw-r- 1 root adm   41297 May  7  2013 /var/log/syslog.6.gz
> april:~#
> 
> It looks like nothing has been written to syslog for the last eight 
> years!

This may seem a stupid question ...
But you have checked the contents of the files haven't you ? I.e. checked that 
they were that old, and don't just have the wrong timestamp due to "some 
unknown problem" ?

Simon

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[Simon Hobson]

Andreas Messer  wrote:

> Once we had a crash in
> simple limit switch device. As a result the high-rack robot pushed a
> pallet in 15m height out of the rack. Fortunately, it was just another
> robot which was destroyed (stood just below) - not a human being. Still 
> a very expensive case for the company. So I'm used implement a lot of 
> checks :-). (Actually we even don't use heap allocation after booting 
> the firmware)

Back in the 90s I had an acquaintance that did a lot of consulting for sites 
with "management issues" and running "big iron". He got a jolly to see a site 
that was run by systems from that vendor - the very early days of warehouse 
automation. High bar warehousing, automated forklifts, with operators riding 
along to move boxes between pallet on the forks and pallet on the racks - it 
was a highly seasonal business, and in the run up to Christmas they be getting 
order in in all sorts of quantities, putting a small box on a pallet is highly 
inefficient so the need for manual handling to combine multiple shipments onto 
one pallet on the racks.
Apparently the average stay before the operators quit from the stress was only 
3 months !
Then one day a forklift went wrong - fortunately with no operator on board. It 
accelerated in an uncontrolled manner until it crashed through the side of the 
building and fell over in the field next door - at which point, all the 
operators walked out !


g4sra via Dng  wrote:

> There is nothing stopping *me* for applying for systems programming work in 
> Nuclear Power Stations, Air Traffic Control, Industrial Robotics, etc...


Yes, but if you look a little deeper, in that sort of industry the programmers 
don't get to "just get on with it". The higher the risk, the higher the degree 
of risk management. By the time the programmer gets to write code, there's been 
a lot of safety based design - and when they've written the code, there's a lot 
of testing and assurance before it can go live.
Of course, if you are Boeing and designing systems for aircraft - then it seems 
it's a different matter !

Simon

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] deprecated options (Was: Refracta have a static IP)

[Simon Hobson]

Bernard Rosset via Dng  wrote:

>> Perhaps it's time for the relevant package to spit out some notice level 
>> logging when it hits deprecated options ?
> 
> I can't imagine the volume of information that would produce on system 
> upgrades, even updates packs.
> Unreadable, if you ask me: Too much information = No information, as it will 
> be discarded.

No, I'm not talking about changelogs - which as you say tend to get very 
lengthy on a system upgrade and either ignored or are a pita to wade through, 
and for many users, much of what's in there isn't relevant to their use case. 
I'm talking about, as a service/daemon starts, then it spits out a warning 
notice **IFF** a deprecated option is encountered in the config.

I've seen the latter many times, and it works - doesn't stop the service 
working, doesn't disappear in a gazzillion pages of changelogs that no-one 
reads (because a lot of the changelog isn't relevant to the user's use case) - 
but does provide a warning that the config needs re-visiting.


Simon

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Refracta have a static IP

[Simon Hobson]

Bernard Rosset via Dng  wrote:

> Documentation states, for both INET & INET6 families:
> address address
>   Address (dotted quad/netmask) required
> 
> netmask mask
>   Netmask (dotted quad or number of bits) deprecated
> 
> Are we really debating how to configure network addresses without first 
> searching in the man pages?

Hmm, that's new since I last **needed** to look in the man page for it - don't 
tell me you look at man pages for stuff you already know how to do, each time 
you do it ?
   Looks like "deprecated" 
was added between ascii and beowulf.


Checking my next oldest system (Debian Wheezy), I see that it includes CIDR 
format. Guess it's a while since I last needed to check the man page for that !


Perhaps it's time for the relevant package to spit out some notice level 
logging when it hits deprecated options ?


Simon

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Refracta have a static IP

[Simon Hobson]

Arnt Karlsen  wrote:

>> So I made my /etc/network/interfaces look like the following, which
>> follows the guidelines of "man interfaces":
>> 
>> ===
>> auto lo
>> iface lo inet loopback
>> 
>> allow-hotplug eth0
>> iface eth0 inet static
>>  address 192.168.0.199
> 
> ..could this be as simple as:
> address 192.168.0.199/24 #??? It shouldn't be.
> 
>>  gateway 192.168.0.1
>> ===

No, in /etc/network/interfaces it needs a net mask line like this :

> auto eth0
> iface eth0 inet static
>   address 192.168.nnn.nnn
>   netmask 255.255.255.0
>   gateway 192.168.nnn.nnn

I usually use auto, but I believe for a "server" type setup then the effect is 
the same as allow-hotplug.

Simon

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ntp setup

[Simon Hobson]

k...@aspodata.se wrote:

>> npt only synchronizes only on machine starts.
> 
> That is wrong, I guess you are thinking about initial sync.
> 
> You can do initial syncronisation with e.g. ntpdate, but ntpd can do
> that also, but can take more time before it decides to jump the clock
> if it differ too much.
> 
> Then ntpd, while running, will at some regular interval,
> syncronize the clock. Run ntpq -p to see the polling interval.
> 
> The ntp.conf file installed with devuan is perfectly fine for
> a newbies always-connected system. If your box only has intermittent 
> connection to the internet, ntpd might not be what you need.
> You might then be better served by chrony or something else.

For clarification ...

From memory, ntp does have problems with clocks that are a long way out of sync 
- or has that been fixed ? I suspect that was part of the reason for running 
ntpdate on startup. As I'm normally working with systems that a) are always on, 
and b) have working hardware clocks with batteries, this hasn't been a problem 
for me so I haven't followed developments.

By default, ntpd will start with a polling interval of 64 seconds, and over 
time will increase this up to 1024s (17 minutes). If you specify an iburst 
value for a peer in the config file, then it will poll several times in a short 
space of time during startup - shortening it's sync time.

As above, ntpq -p will list the currently configured peers and their status. 
After a while, one will be listed with "*" before it's entry - this is peer it 
currently considers the primary and which it will sync the clock. Others marked 
with "+" are candidate to be the primary.

My configured servers are :
server ntp.plus.net
server ntp2b.mcc.ac.uk
server ntp2c.mcc.ac.uk
server ntp.cis.strath.ac.uk
server ntp.ox.ac.uk

$ ntpq -p
 remote   refid  st t when poll reach   delay   offset  jitter
==
-cdns01.plus.net 195.66.241.3 2 u  396 1024  377   30.702   -0.750   0.322
*frome.mc.man.ac 193.62.22.66 2 u  452 1024  377   39.6840.277   0.231
+utserv.mcc.ac.u 193.62.22.66 2 u  317 1024  377   39.488   -0.010   0.382
+ntp0.cis.strath 193.62.22.74 2 u  630 1024  377   42.8580.002   0.672
 ntp0.ox.ac.uk   .STEP.  16 u- 102400.0000.000   0.000

Taking the second line from this, it says my local daemon is synced to 
frome.mc.man.ac[.uk] (ntp2b.mcc.ac.uk is an alias to frome) which in turn is 
synced to 193.62.22.66. Frome is a stratum 2 server, it was last polled 452 
seconds ago, the polling interval is now 1024s and it responded for each of the 
last 8 polls (377 in octal is  , if any poll fails, then the reach 
column will indicate this with a 0 for each poll that failed). The round trip 
time for the poll was a little under 40 ms, the local clock is offset by .27ms, 
and the jitter (variation in round trip time and time offset between polls) is 
0.23ms.
I'm assuming ntpd has selected this peer because it has the lowest jitter. If 
there were peers with different stratums, then ntpd will favour the higher 
stratum ones - stratum is basically how many hops from a "high quality" time 
source (such as the atomic clocks run by the likes of NPL).

ntp0.ox.ac.uk has never responded (must get round to removing that some time), 
and I think cdns01.plus.net (ntp.plus.net) has been discounted as a candidate 
for primary peer because it's clock disagrees with the rest.

On another system I see :
$ ntpq -p
 remote   refid  st t when poll reach   delay   offset  jitter
==
*patsy.thehobson 130.88.203.133 u  423 1024  3771.079   -0.125   0.237

showing that the ntp daemon running on patsy is stratum 3 because it's synced 
to a stratum 2 peer.


As said, just installed the ntp package should give you a working time sync - 
using four servers from the ntp.org pool. If your clock is not syncing, then 
the first debugging tool is ntpq -p and see what is going on.


As an aside, you may find this interesting to see how some miscreants are (or 
were, it was written 5 years ago) using the Debian pool to find devices to port 
scan.
http://netpatterns.blogspot.com/2016/01/the-rising-sophistication-of-network.html

Simon

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] network measurement

[Simon Hobson]

Ludovic Bellière  wrote:

> You could also explore alternatives to zoom, like the FOSS 
> (jitsi)[https://jitsi.org/].

FWIW, of all the options I've used on my (rather old, 2005 model) Mac, Zoom has 
the lowest load. Jitsi is considerably higher, and I have to manually turn down 
the video to the lowest setting to get the CPU usage at anything but maxed out.



mett  wrote:

> When you are sure your LAN is OK,
> you can just ping with different size and options:
> 1/the pppoe concentrator of your provider,
> which is usually the first hop from your WAN address,
> 2/the next hop
> 3/the next-next hop
> and so on.

Matt's TraceRoute (mtr) is handy for troubleshooting. It's sort of a cross 
between ping and traceroute - continuously shows round trip times and packet 
loss to each hop down the route. When you are in a situation where you think 
you are losing packets, keep it running and watch the stats while you are doing 
things that stress the network - dropped packets tend to show up fairly quickly.


> That said, DSL is quite old technology,
> according to Wikipedia, the latest protocol
> allows 24Mbit/s upstream and 3.3Mbit/s downstream
> (those are just standards number, so with overhead
> you will certainly get way less).

That sounds like ADSL2, which is only one variant of DSL. DSL is definitely not 
old tech, it's pretty well the mainstay of all non-cable connections in the UK 
- whether it be ADSL2 (up to 24M down, earlier ADSL was up to 8M down), VDSL 
(or in marketing speak, "superfast" or FTTC) which in the UK does up to 80M 
down, or now they are trying to roll out gFast in some places which does some 
much higher speed but only over ridiculously short distances (literally from 
pole to house).


As to the original question ...

MTR is a useful tool for visualising data, either on it's own with your own 
hand-rolled scripts, or with Cacti. You can pick up interface traffic stats 
from somewhere in /proc/net - or Cacti will (IIRC) automate that for you (but 
only does down to 5 minute resolution by default).
At my last place I put in place monitoring using some bash scripts and MTR - 
before that we had no idea what was using the bandwidth, only that the VoIP 
didn't work very well at busy times.
The next step was to put in place traffic shaping - which you can do yourself 
with the native tc tools (I suspect replaced with something in the netfilter 
tools now), or (as I did) use Shorewall to give a higher level of abstraction 
(along with routing and firewalling.


Simon

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] FSF and human rights

[Simon Hobson]

> On 27 Mar 2021, at 03:55, John Morris  wrote:
> 
> On Fri, 2021-03-26 at 15:46 -0400, Steve Litt wrote:
>> 
>> I'd suggest nobody sign anything, and nobody respond to this email.
>> 
>> If you believe that Stallman was removed, shunned and criticized
>> because of guilt by association, then it's not much of a stretch to
>> believe that you will suffer the same fate if you defend him. And then
>> any who defends *you* will suffer the same fate, ad infinitum. 
> 
> This exactly how a "climate of fear" works.  Anyone who has looked three
> seconds at the Cultural Revolution or any of the other descents into
> madness of the 20th Century knows exactly what is going on here.

Agreed.
The very first thing that went through my mind when I read SL's post was ...

https://en.wikipedia.org/wiki/First_they_came_...

> First they came for the socialists, and I did not speak out—
>  Because I was not a socialist.
> 
> Then they came for the trade unionists, and I did not speak out—
>  Because I was not a trade unionist.
> 
> ...


I met RMS when he did a speaking tour over here in the UK a while back. I can 
fully understand the comments people have made about him being the most 
infuriating person to deal with. But then, people with principles usually are 
in my opinion - the ones you need to watch out for are the ones who put "being 
liked" high on their list of priorities. With people who hold on to their 
principles, yo know where you stand - even if you don't like them. With the 
latter type you don't know where you stand - but best not turn your back lest 
you (figuratively) get a knife in it.
I can say that for all his annoyances, his principles were clear - and held 
nothing whatsoever that I could imagine any **reasonable** person finding 
argument with.

As to Debian, well one thing that goes through my mind is how flipping 
hypocritical they are when the Debian project would almost certainly not even 
exist if it weren't for RMS and both his technical output and his principled 
stance.

Obviously individuals will need to consider their own situation. I will be 
signing in support of RMS. In the UK we still have (in spite of attempts by 
some to copy the worst ideas to come from the USA) a number of protections - so 
I have zero worries about losing my employment etc. And as I'm not on 
FaecesBorg I don't need to worry about that.

My 2d worth, Simon

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Motel wifi: was web conferencing software

[Simon Hobson]

Rick Moen  wrote:

>> That latter point means that you go to https://myfavouritewebsite.com
>> and no you don't get the portal page - you get a certificate warning.
>> Given that most people these days will have https URLs cached in their
>> browser, you have to manually and explicitly try and connect to a site
>> (doesn't matter what, any random URL will do) over HTTP.
> 
> Counter-tactic:  If you're in a place (hotel, motel, conference centre)
> where you suspect there might be a captive portal, fire up first an
> _alternate_ Web browser (after temporarily disabling one's bespoke
> choice of DNS nameserver IP), and try to load something, to see if the
> captive portal page shows up.  After navigating any captive portal,
> switch to your production-use Web browser.
> 
> Equivalently (I think?), use a private-browsing tab for the first page
> load.

Indeed, a number of ways around the problem. I usually just open up a new 
window and navigate to (not literally) http://some_site_I'm_not_going _to_use 
so I don't poison the system DNS or browser page caches for any site I am 
planning to use.
Doesn't help for all the stuff that automatically tries to connect in the 
background and starts popping up certificate error messages while you are 
trying to get the problem fixed. The last thing anyone wants when there's a 
problem you are working on is more alerts telling you about the problem !

Mind you, not all captive portals work that way.
I've seen at least one that gives you genuine DNS results, but intercept the 
port 80 traffic (and I assume block the rest). A "VPN over DNS" tunnel would 
probably be a workaround, but I've never been bothered enough by this one to 
make the effort worthwhile - the only time I recall seeing it was many years 
ago when I was abroad with work.

Simon
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Jitsi-meet server in DMZ

[Simon Hobson]

g4sra  wrote:

>> It is as simple as needing to connect to the server at different IPs (i.e. 
>> the internal IP from inside, the external IP from outside), but using the 
>> same URL ? 
> 
> In a nutshell, yes.

OK, then I'd use split horizon DNS - problem solved (but noting the comment 
made about Android).
As also noted, SIP is one of the things that is well and truly screwed up by 
NAT - not that you'll find many NAT apologists admitting that. And in my 
experience, SIP ALGs (Application Level Gateways) can screw things up more than 
they fix.

>> If so, then split horizon DNS is your friend - and I'm assuming that's 
>> what you are referring to when you say using BINDs response policy.
> No.
> 
> BIND's 'responce policy' is a, um, policy similar to a normal zone BUT 
> anything in this zone can mask a real resolve from occurring.

I hadn't seen that one, it's newer than when I last setup a BIND server.


>> Some will tell you that it's wrong - but as long as we have NAT then it's a 
>> decent and reliable workaround for the breakage that NAT causes.
> The reason it is wrong is...your internal DNS server is exposed to to a 
> higher hacking threat than if you had two separate servers, with the one in 
> the DMZ serving external queries and the internal one on the local lan behind 
> a secondary firewall.

It can be done with two different servers, and that's (sort of) actually how I 
have it. My own server is not internet accessible other than from secondary 
servers at a hosting company which publicly host my external zone for me.

But the reason I was told, with absolute certainty" by a supposedly 
professional consultant is that firstly I should not have different servers 
with the same name - e.g. internal and external web server for the same domain. 
But mostly, I should not be running my own DNS because only our ISP could keep 
our zone up to date !
In hindsight, with a little effort and guided learning I could have been a 
consultant with that sort of job - except that I never had, and never had the 
desire to have, the gift of "bulls**tting my way through anything".

Simon
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Jitsi-meet server in DMZ

[Simon Hobson]

g4sra via Dng  wrote:

>>> The meeting being hosted on the server needs to be simultaneously
>>> accessible as two different domains, internal.com and external.com.
>>> Anyone achieved this yet or know a better way ?

> Decided to use the external FQDN and implement BIND's response-policy' lying 
> to the internal domain.
> If anyone can think of a good reason why this is a bad idea please shout.

Can you clarify what the issue is ?
It is as simple as needing to connect to the server at different IPs (i.e. the 
internal IP from inside, the external IP from outside), but using the same URL 
? If so, then split horizon DNS is your friend - and I'm assuming that's what 
you are referring to when you say using BINDs response policy.

I run split horizon DNS at home. I have an internal zone for thehobsons.co.uk 
which has internal addresses for my devices, and an external zone for it which 
lists only the public IPs. Two views (in BIND terminology), with rules applied 
to determine which view is used for which clients.
Some will tell you that it's wrong - but as long as we have NAT then it's a 
decent and reliable workaround for the breakage that NAT causes.

Simon

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Motel wifi: was web conferencing software

[Simon Hobson]

> On 8 Mar 2021, at 14:08, Steve Litt  wrote:
> 
> Rick Moen said:
> 
>> The above is a vexing problem for travelers w/laptops who prefer to
>> specify their own choice of nameserver and still use hotel/motel WiFi
>> (and wired ethernet, actually).  Best case, you have to disable your
>> nameserver IP override long enough to navigate the captive portal, and
>> then can put the override back.  But, no, you cannot just leave your
>> choice of nameserver IPs in place (without disappointment).
> 
> This is good information. I've sometimes wondered why I couldn't log in
> at the library or Macdonalds.

And the other thing they screw up is that by redirecting you, nothing presents 
the right certificate ! I hate using such public connections because it's so 
much hassle remembering to put every bit of software into offline mode first - 
if you don't then I get a flurry of certificate warnings and it can mean 
quitting and re-opening software for it to pick up the now correct IP address. 
But if it's a choice between that or nothing then ...

The process is simple enough. When you are not an authorised user, the captive 
system responds to every DNS request with the IP of it's captive portal. For 
HTTP requests that's simple enough - you get their portal page instead of what 
you were asking for. Once you've signed in (and possibly had to pay for it !), 
then you get the right IP addresses returned.
But of course, your system has cached the wrong address and may or may not 
flush it in a timely manner. Your browser has cached the portal page instead of 
the real page (assuming it was an HTTP request). And everything using secure 
connections, gives you certificate errors.
That latter point means that you go to https://myfavouritewebsite.com and no 
you don't get the portal page - you get a certificate warning. Given that most 
people these days will have https URLs cached in their browser, you have to 
manually and explicitly try and connect to a site (doesn't matter what, any 
random URL will do) over HTTP.

Simon

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OT"? Wanted a simple 2d plan drafting/sketching/plotting program

[Simon Hobson]

terryc  wrote:

> I need to sketch a plan of a land plot for an erection by a
> contractor. the 'erection' can be described as three to five rectangles
> with ramps between them. Ancillary data to be plotted/drawn is building
> sides, pathway and drive way. placement of shrubbery is optional. I'm
> really after a vector based program.
...
> I come from the world of drafting where first you define your scale,
> then draw up your plan to scale. the problem there is I've spent the
> last three days intermittently looking at eight CAD/sketching programs.
> 
> Bummer, as nothing 'sets a scale' any more. Apparently the 'modern'
> approach is to describe it in 'elements' of real world dimensions and
> then scale the result.

It might be worth having a look at http://www.sweethome3d.com/

It's not really designed for 2D work - but it can do a 2D plan view of any 
floor. It's not too hard to get going with, but it is geared up for building 
houses etc. You'd define your different levels by creating them as blocks 
placed on ground level - with their height as whatever you want the elevation 
of that surface to be. And I'm afraid (unless they've enhanced that since I 
last did anything with it, or I've missed something important) your ramps will 
need to be a series of steps as the only things that support sloping tops are 
roofs.

What is fun is setting your illumination and then going around (and inside) 
with your viewpoint :D


I think I understand what you are saying about scaling. But really, "setting a 
scale" was one of those things that was done simply because before things went 
all computerised, it wasn't possible to work how things do it today. BTW - I 
trust you've never worked with "scales" then, like a ruler, but marked in 
scaled units to save having to calculate a scaled length of each measurement ? 
Working with a scale would be exactly like the modern computer method of 
working in real world units and scaling the output to (e.g.) fit the drawing on 
one sheet of paper. The other advantage of working with real units and then 
scaling the output is that you don't have to pre-define your output drawing 
size before you start work - so can easily do A4 at home, or get someone to run 
it off on their A0 plotter if you need a big detailed drawing.

Ask yourself, do you think "that  is 4 inches long on the drawing 
which equates to 16 feet", or do you think "that  is 16 feet long" 
(because you've taken that directly from the printed scale) ? Of course, you 
should always be reading the numbers that are printed against dimension lines - 
obeying the "do not scale" instruction on most drawings.

Simon

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Opennic

[Simon Hobson]

Gabe Stanton via Dng  wrote:

> You're right that I didn't address the fact that queries to root
> servers don't all go to one server. My understanding of that wasn't
> firm when I was writing so I said 'upstream server'. But that would be
> a small hurdle to overcome if everyone started protecting their dns
> queries by running a caching resolver, because of the financial
> incentive for doing so. The collusion it would take to exploit all
> exploitable data would be minimal.

I beg to differ. It would need a great deal of collusion (at least for the root 
servers), involving a variety of entities from around the world - and it only 
takes one of them to blow the whistle. If anyone tied it, it would kick up 
quite a storm. At the very least, it is not something that could be done 
without anyone realising.


> Those are great arguments for runnning a caching resolver, and of
> course that's a good thing, but there are a couple cases I outlined
> that potentially offer better privacy. 
> 1. Running your own recursive server where your dns requests are pooled
> with others. 
> 2. Pointing at a single resolver that doesn't keep logs and where your
> dns requests are pooled. Of course you never know what logs are being
> kept for sure, but if operators are honest and don't keep logs, and if
> they run doh, dot, or dnscrypt, then you have potentially better
> privacy because of no logs and pooled requests.

It occurred to me (after writing my previous message) that one option open to 
you is to get together with a few friends and share a resolver that's under 
your own control. You could turn off query logging and then know that there's 
no logs for anyone to look at. The difficult bit is getting enough people 
together who all trust each other such that you can pool enough queries as to 
make any data collected by others into useless noise.


But also as mentioned earlier, none of this deals with the eavesdropper 
problem. Your ISP can look at all your DNS queries just by filtering out all 
port 53 traffic and copying it to their logging servers. I suspect in some 
jurisdictions that's done because "the authorities say so", and I'm sure that 
some will be doing it because the law doesn't stop them and it's something they 
can monetise. As Rick Moen says, the only defence against that is to deal with 
an ISP that isn't run by sleaze balls.

And that problem was behind the development of DoH - which simply replaces one 
problem of trust with a different problem of trust !

Simon
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Opennic

[Simon Hobson]

Gabe Stanton via Dng  wrote:

> Of course using a local (or controlled by you) caching dns resolver
> ENHANCES privacy. That's not even a question and doesn't represent a
> real argument against the likelihood that, in the case of everyone
> running their own caching resolver, that second level nameservers would
> end up being a very good source of info to match dns requests to ip
> addresses, to be exploited just as any other big dns provider is likely
> to do. 

I think you missed that if you use an external service for resolution, then 
**ALL** your queries go via one point - so there's a single point someone can 
slurp that information from. Obviously, the inclination to slurp that data and 
use it in ways we aren't happy with will vary between providers.

Once you run your own local resolver then important things happen.


The queries are now not concentrated at one point.

Yes, you are correct that if you visit (e.g.) www.amazon.com, then your local 
resolver will go to the .com tld servers to find the NS records for amazon.com 
- but it will only do that once every 2 days and so the .com tld servers will 
only see ONE query every two days regardless of how often you visit anything in 
the amazon.com domain. The fact that the frequency information is vastly 
diluted significantly reduces the value of that information.
Also, the .com tld servers will have ZERO visibility of you visiting 
www.amazon.ch (or in my case, amazon.co.uk) because no query for that will go 
near them.
Similarly, once your resolver has the amazon. ns records cached, 
nothing other than those nameservers will see whether you switch from (say) 
www.amazon.whatever to smile.amazon.whatever.

So to gather even a fraction of what you can get from clients using one source 
for a resolver, someone would need to get information from multiple different 
sources - run by different entities. Once anyone tried that, then it's a lot 
harder for them to hide what they are doing - if some commercial entity were to 
go round asking various tld server operators for data, then it's highly likely 
that at least one of them would go public with this information.

Because different domains use different servers, without getting data from many 
sources, no-one can correlate your DNS lookups to work out your path around the 
internet. They may be able to get snippets of it, but not the detail they'd get 
by seeing all your queries and being able to time correlate them.


As already mentioned, what information you do leak is limited in volume.
Once your resolver has cached information, it will not go upstream to request 
it again until it's TTL expires. So regardless of how frequently you go 
somewhere, upstream will only see a small volume of that.


I've never looked into it, but I suspect that at least some packages might 
offer a config option to not send the full query string upstream.
The default is that if you lookup (say) www.amazon.com and nothing is currently 
cached, then I know that BIND will send that query string to the root servers - 
which will replay with the NS records for the .com zone. BIND will then send 
the full name to the .com servers which will respond with the NS records for 
amazon.com domain. In principle (though there are some complications that would 
need to be worked around), it would be possible to only ask the root servers 
for the NS records for .com, and then only ask the .com servers for the NS 
records for amazon.com - whcih would significantly mask your activity.
As I say, there are some complications, and I don't know if any package 
actually offers that ability.


Simon
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] What does this remind you of?

[Simon Hobson]

Dr. Nikolaus Klepp  wrote:

>> I doubt this could be ever implemented correctly as you have to check
>> every code path of every app you will armorize or as soon as your usage
>> diverges from what the distro gurus have envisioned your program
>> will stop working without even a warning.
>> Next then we will need a uber-apparmor that checks apparmor safety
>> and anyway more code more bugs less security. Why not fix the existing
>> programs instead?
> 
> The point is to delegate access control to a higher instance e.g. kernel. The 
> problem is, that apparmor looks at a program from the the outside and tries 
> to do the right thing with that black box - or what the profiles provider 
> thought was the right thing.
> 
> OpenBSD has quite an interesting aproach with unveil ( 
> https://man.openbsd.org/unveil.2 ) and pledge ( 
> https://man.openbsd.org/pledge ). The programmer itself takes care what the 
> program will use and tells the system that what e.g. access privileges it 
> does not want to use from now on. That's the look at the world from the 
> inside, no black box involved. If you droped things, you can never get them 
> back, so evil hackers code is confined inside the same cage.

As I see it, both approaches have merit.
The downside of doing it inside the application is that you are then trusting 
the programmer to have got the protection code correct - when we are assuming 
the function of the protection code is to protect from the programmer's errors. 
Yes, dropping privileges is a good idea - as long as it's done reliably.
The alternative of looking from the outside at a black box is that the person 
doing the looking was not the one building the black box. Thus while you lose 
the granularity possible when doing it from inside the box, you have created a 
separation of functions.

I don't think either approach is "right" or "wrong" - but doing both would 
probably be best.

Simon

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] My Qemu LAN-peer documentation is now in its first draft

[Simon Hobson]

Steve Litt  wrote:

> The vast majority of documents I've read tell me that once you make the
> bridge, the hardware NIC must be robbed of its IP addresses. So that's
> what I did.

That is the correct way to do it - though from memory it does seem to still 
work for host-LAN communications if you use an IP address on the physical NIC. 
By putting IP address(es) on the bridge, it's functionally identical to having 
a host virtual NIC which connects to that bridge and hence via another NIC to 
the LAN. To a certain extent I think the relationship between a host physical 
NIC and a virtual bridge it's connected to can be a bit schizophrenic as I 
notice that my bridge has the same MAC address as the physical NIC it's 
connected to - possibly it just gets the MAC address of the first NIC to be 
connected to it though I've never tested that.


There is one thing I'm unclear about in your document, and that's the object 
you refer to as mybridge0.

My experience is with Xen, which is configured almost identically to how you 
show it, and I believe uses QEMU for some functions. What you call mybridge0 
and describe as a bridge, in the Xen world is (by default) called vifn.m‡ and 
is a virtual NIC. I'm suspecting that what you call mybridge0 is in fact a 
virtual NIC which connects to the bridge br0.
Thus what you have is the bridge (analogous to a network switch), with a 
virtual NIC (mybridge0) connected to it - then there's a virtual point-point 
network link between that and eth0 in the guest.

I'm guessing that "brctl show" will probably show something like this :
bridge name bridge id   STP enabled interfaces
br0 8000.2cf05d7a5c1d   no  enp40s0
mybridge0

‡ Where n is the id (number) of the guest, and m is the interface number 
starting with 0 for the first and incrementing if multiple VIFs are created. I 
forget how many I've got to with one guest, I don't think it was double digits 
although it must have been close !
I don't actually use the vifm.n format - I prefer to manually specify 
"meaningful" names (specified in the network section for creating a Xen guest) 
that make it easier to see what's connected to what.

If you do see that, then it would avoid a lot of confusion to do a global find 
& replace to rename mybridge0 to something more like a NIC.

https://wiki.xenproject.org/wiki/Xen_Networking#Paravirtualised_Network_Devices 
may help

Oh yes, and use a different name for each guest - having two guests configured 
to use the same name for the host end of their virtual link produces 
"interesting" results.



Lastly, there is a definite point of correction to be made.
A bridge/switch is **NOT** "kinda-sorta like a network router in that it 
connects two distinct IP address ranges into one network", and nor is it a hub 
(though it does behave at the most basic level in the same way). A switch is IP 
address, and even protocol, agnostic - unless you apply filtering (e.g. 
ebtables on Linux) then it simply forwards packets without caring what is in 
them. In this respect, it is mostly definitely in no way "kinda-sorta like a 
network router" !
The difference between a bridge/switch and a hub is that a switch is clever 
about which ports it sends traffic out on. It keeps track of what MAC addresses 
are connected to each port, and will only send a packet out of the appropriate 
port. Thus point-point traffic does not appear on other links - which means 
that (e.g.) A can talk at full wire speed to B, while C can talk to D at full 
wire speed assuming that A-D are connected to different switch ports.
A hub is "dumb" - every packet it receives is simply repeated out of every 
other port with no buffering or delay. Thus every node in the network sees all 
traffic, and the entire network is one flat collision domain. With a switch, it 
will queue packets destined for a port that is already carrying a packet - and 
thus splits the collision domain up.
https://en.wikipedia.org/wiki/Network_switch

On Linux, you can see the MAC forwarding table (for bridge br0) with "brctl 
showmacs br0" which should produce output like :
port no mac addris local?   ageing timer
  1 00:16:3e:xx:xx:xx   no24.96
  4 00:16:3e:xx:xx:xx   no 0.13
  1 00:1e:0b:xx:xx:xx   yes0.00
...
00:16:3e is the OUI prefix used by Xen - so those first two lines are virtual 
machines


Simon

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Stable identifiers (Was: My Qemu LAN-peer documentation is now in its first draft)

[Simon Hobson]

tito via Dng  wrote:

> I wonder why instead of predictable names they didn't choose
> prefix+mac_address at least for initial setup of names and leave it
> to user to name the interfaces they way he likes. This would have
> guaranteed (almost) unique persistent names and by using standard
> prefixes would have identified easily the class of network device.

As suggested already, this is Freedesktop.org - so logic and simplicity are not 
allowed. Far better to force admins to keep changing a miriad of configs 
whenever IF names change and break things than to allow a sensible and reliable 
mechanism to have things stable. It's a variation of Apple's "you're holding it 
wrong" attitude to user expectations.


FWIW, there's a different but related issue with DHCP.
With DHCP for IPv4, an identifier included in packets is the MAC address - more 
technically, Client Interface Address as non-ethernet interfaces are also 
supported (e.g. token ring). And many workflows rely on this as a stable client 
identifier - even though it can change.
For whatever reasons that may have made sense at the time, with DHCP for IPv6 
this was explicitly not done "because MAC addresses can change". Instead, a 
DUID (DHCP Unique Identifier) was created to be the sole identifier for a node 
- note node, not interface, the DUID would be the same for all interfaces on a 
node. Result ? The DUID changes a lot more than the MAC address ever did ! 
Absent any standardised way of storing it in the machine on typical hardware, 
any re-install or change of environment can change the DUID unless the admin 
takes steps to preserve it.

And I've had a problem with this. Built a new VM, found it kept changing 
address on every boot and my reserved lease for it was ignored. I find that for 
some reason I can't figure, when it starts up it doesn't have a DUID and so 
creates a new one - so to the server it's a different node and gets a new 
address. By the time the system mounts the real /var from disk (where the 
stable DUID is stored), the network is already configured - a manual 
ifdown-ifup cycle will get it it's correct address. I think the client leases 
file (which contains the client DUID) should be included in the initram image 
but doesn't get used. Interestingly, I tried adding some debugging to the 
network scripts - and the timing changes they produced changed this behaviour !

Simon
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] My Qemu LAN-peer documentation is now in its first draft

[Simon Hobson]

Florian Zieboll via Dng  wrote:

> For the sake of completeness and y'all's convenience, here a link to the
> related info in the Debianwiki:
> 
> https://wiki.debian.org/NetworkInterfaceNames

Did anyone else read that and think it could be summarised along the lines of :
"We thought X was badly broken, so we developed Y which will require you to 
reconfigure lots of stuff - but even we have to admit that Y is actually more 
broken and here's the complicated ways to get sane behaviour"

Simon

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] GNUPGP Web of trust

[Simon Hobson]

Gabe Stanton via Dng  wrote:

> Is it as simple as inviting anyone that wants to, to send their public
> key to this list? I'm not experienced in web of trust common/accepted
> practices but have been interested for some time.

No, it's not that simple !

Try this for starters : https://en.wikipedia.org/wiki/Web_of_trust

Simon

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Very offtopic: 70's music

[Simon Hobson]

Stephane Ascoet via Dng  wrote:

>> Of course, the 80's were better, and the 90's were even better than
>> that, but the 70's were no slouch when it comes to music. If you skip
>> disco.
> 

> Hi, it's a joke? 70s are considered by lot of people to be the best decade in 
> music, just some examples: Crosby Stills Nash and Young(and every various 
> related combination of these four guys), Fleetwood Mac, Eagles, Genesis, Pink 
> Floyd, Elton John, James Taylor,  Jackson Browne, David Bowie, Eric Clapton, 
> Led Zeppelin, former Beatles in solo, Dire Straits and Michael Jackson 
> debuts...

I think it's a case of two things :

1) Everyone has different tastes - what someone might think of as rubbish is 
someone else's favourite.

2) All periods had some good music, and all periods also had some ... lets just 
say not so good music. Where "good" depends on preference - see 1 above. If you 
mostly didn't like the music that characterises a period, then you will tend to 
remember the stuff you didn't like - and hence "all music from ${period} is 
rubbish". Similarly, there's a tendency to forget the best forgotten stuff from 
a period you otherwise liked - and hence "all music from ${period} was great", 
as long as you forget the stuff you couldn't stand ;-)

And added to that, people's preferences change. I now listen to stuff I would 
never have dreamed of listening to a couple of decades ago - but find myself 
thinking that "hmm, actually I quite like that now". It can also work the other 
way round, but I can't immediately think of any in my case.


In my department at work, the fortnightly new letter has a Desert Island Disks 
section where someone from the department picks 8 tracks, gives a little bit 
about themselves, and a little bit about why they chose each track. I was on a 
few months ago - and boy, was it hard picking those 8 tracks.
But, it's interesting to look at people's selections, and often I'll be 
thinking "yes, I like that" and "hmm, I'll give that a go - not thought of 
listening to that before". It has slightly broadened my taste in music - which 
was already rather wide and eclectic to start with. After this morning's list, 
Eminem is still not on my list of stuff to listen to though !


Getting slightly on-topic for this list, there's parallels with taste in 
software. Clearly most people on this list are a self selected group who put 
freedom (of init) above other considerations. There are others who put "ease of 
use" first. Some who put absolute "free and open" above all else. Some who are 
more pragmatic and accept that sometimes non-free or non-open is acceptable 
when it comes to getting work done.
There isn't a right or wrong - just a "best for your preferences" compromise.

Sorry, couldn't resist this quote : https://www.youtube.com/watch?v=jVygqjyS4CA

Simon
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why X does keyboard and mouse.

[Simon Hobson]

Hendrik Boom  wrote:

 It didn't have to be this way. In 2020, better alternatives could
 have been made. If I were the project manager, the first thing I'd
 do is uncouple keyboard, mouse and video from each other. Why X has
 anything to do with keyboard or mouse is beyond me.  
>>> 
>>> Perhaps because X was originally a means of having a graphical user
>>> interface to multiple machines over a network.  Which usualy involves
>>> a screen, keyboard, and mouse.
>>> 
>>> Each X window could be talking to a different computer.  It mattered
>>> which computer your keystrokes went to.
>> 
>> Yes, but that doesn't preclude three or more separate pieces of
>> software: One for the screen, one for the keyboard, and one for the
>> mouse. There can be others as input devices are added. There could even
>> be a struct that passes a pointer to each of those three (or more).
> 
> The X server would still have to take the keystrokes, see which window was 
> active and sent those keystrokes to the remote machine using that window.  
> That 
> connects them together.

...

> But when the X inventors did this, they left out audio.  I can connect to a 
> remote host, run a media player, and never hear the sound, because it's 
> playing 
> on the remote host.

In some ways that's an argument for doing some form of multiple streams - and 
multiplex them down one transport. That way, you implement the stream types you 
know about now, and when new ones come along (e.g. people now want audio rather 
than just a beep) then it can be easily added as an additional stream type.
Intelligent multiplexing should be able to retain the sequence of (e.g. key 
presses and mouse clicks), though I guess there's always the chance that 
processes could get scheduled in such a way that very closely spaced events 
might get re-ordered. Such an example could be if you hit a key and click the 
mouse together - but given the processing abilities of modern hardware, I think 
it would need to be "together" (from human response times PoV) for it to be a 
risk.

But really it's a moot discussion. It didn't happen, and it's not likely to 
given the vested interests in pushing their own ideas these days.

Simon

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Apollo computers (Was: savings from parallelism)

[Simon Hobson]

Didier Kryn  wrote:

> I remember these Apollos. They were shining and ran some brand of
> Unix if I remember well. We had a few in my lab but I never got a chance
> to touch one.

I knew "just about zero" about Unix back then so can't comment on how they 
compared with anything else. The OS was Domain/IX (or something similar) - ah, 
wonders of modern search engines, Domain/OS 
https://en.wikipedia.org/wiki/Domain/OS And now I read that, I also recall 
AEGIS being part of the name somehow.

See also https://en.wikipedia.org/wiki/Apollo/Domain
Brings back some details. We had the DN1 as a number cruncher, and before 
it got locked down, I recall it was blazingly fast compared to our workstations 
- one of the "demo" programs around on the network did real-time calculations 
for a load of bouncy balls "tipped into the top of the screen" (so the dynamics 
of gravity, plus the dynamics of collisions between the balls and boundaries or 
other balls) and the DN1 could do the maths (I guess, from memory) an order 
of magnitude or more faster judging by how much better the balls moved when the 
maths was done remotely. Reading the articles, I guess we probably had DN3000 
workstations.

But the one outstanding feature of the system was it was designed to run a 
network. Every file on any system on the network was located under one tree. 
While we are used to "/..." starts at the root of our own box's file system, on 
the Apollo Domain system, they all came under "//..." with "//https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] savings from parallelism (Was: if2mac init.d service for persistent network interface names)

[Simon Hobson]

Didier Kryn  wrote:

> Therefore I suspect the authors managed to launch several threads in order to 
> save 0.01s of the boot time. Or to loose more because thread scheduling might 
> well consume more than what parallelism saves.

In the general case, parallelism only saves wall clock time IFF you have a 
number of processes that have to wait on outside events while not 
(significantly) using resources on the machine - or if they are exceedingly 
computationally intensive that running tasks across multiple cores gives a 
saving (not common during startup). So if you have things like bringing up 
interfaces - waiting for WiFi to connect and DHCP to get an address, that sort 
of thing. But even then there's probably little to be saved since you usually 
have most of the system waiting for the network to be up before it can proceed.
But otherwise, especially with a spinning disk, parallelism will slow things 
down because you force the disk to go off here there and everywhere getting 
data for different processes. Not applicable during startup, but there are 
memory considerations* too if the jobs are large. With SSD this is much less of 
a problem.


* As an aside, at a previous job many years ago, they got a network of Apollo 
workstations in for running engineering software. The whole thing was primarily 
driven by the naval architects for doing complex fluid dynamics and structural 
modelling - and at the time Apollo had the higher spec number cruncher. For 
context, this was when a 286 with a couple of megs of RAM was considered high 
end - Apollo were using (from memory) Motorola 68000 range processors and I 
think most of the workstations had 68020. They had to stop people running their 
own jobs on the big machine simply because if asked to run more than one then 
it would slow to a crawl when it started swapping. But users were unable to 
grasp the concept of "wait your f'in turn" (some would even cancel other 
running jobs to get theirs to run faster) - so restrictions were imposed and 
only the admins could run jobs on it, everyone else had to put their requests 
in a queue.

Simon

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Ethernet names revisited

[Simon Hobson]

Hendrik Boom  wrote:

> I had to solve it by assigning new names to the interfaces (thus not eth0 or 
> eth1) and modifying all the config files mentioning those interface names (I 
> found them with grep) to use the new names instead.

Not for the OPs reason, but a long time ago I started to use "meaningful names" 
like ethext, ethint, and so on. Making it clearer in config files what each 
interface is. On one box (router) I had a fair number of interfaces (I can 
recall at least 8 inc 3 PPP (VDSL2) networks) - made remembering what's what a 
heck of a lot easier. Also did the same thing with my Xen guests - gave the 
interfaces on the host meaningful names via the guest config files.

I think removing the need to remember something is better than being good at 
remembering it (which I'm not anyway !)

Simon
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] godaddy (was Your system is not supported by certbot-auto anymore.)

[Simon Hobson]

Hendrik Boom  wrote:

> Know any domain registrars that don't mess with the user?

You could take a look at mythic-beasts.com or portfast.net

When I left my last place, I decided to move my domains away from them (as an 
employee I got "cost price" domains and free hosting) - knowing that the people 
left in charge are (staying polite) "ethics challenged" and "technically 
challenged". Good choice as it happened, because one "person" decided to just 
switch off* the remaining servers - "DNS will be OK, it's all mirrored at 
Portfast". I had mixed emotions when I heard that they'd been in a panic to 
setup about 100 remaining domains on their preferred hosting platform (with a 
truly horrible GUI for managing DNS) after a week when the secondary DNS 
servers expired all the records - a strong sense of schadenfreude as their own 
domain was one of them, but with my professional hat ot a distinct sense of 
anger that a) it had impacted clients, and b) they'd be told a bunch of lies as 
to why it had happened.
* Didn't just switch off, but switched off, and ripped out of the rack and all 
the networking ripped apart - so couldn't just switch it back on again.

Anyway, my personal domains are now mirrored at Portfast - they were before as 
we used them to mirror our primary (have a neat API to keep their list up to 
date with ours). And on a recommendation from someone in my local-ish LUG moved 
my registrations to Mythic Beasts. What I can say is that when we were setting 
up our secondary DNS service at Portfast, we had good support dealing with real 
people in technical roles - not support droids with a computer flowchart. We'd 
previously had a secondary service from another UK supplier (Gradwell) who'd 
decided to pull out of that side of things - and they arranged to transfer our 
service to an equivalent one with Portfast rather that the more typical 
approach of "we're turning your service off, bog off and find another service 
yourself".

And I see that I'm now down to around 5 years left on my domains - so time to 
extend that back up to 9+ years. Like you, I don't subscribe to the "year by 
year and leave it late" renewals policy. We had clients with domain name 
problems caused by that. Of course, the alternative problem is that you "know" 
there's a long time left and the years can roll by faster than you realise :-(

Simon

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Your system is not supported by certbot-auto anymore.

[Simon Hobson]

Simon Walter  wrote:

> Other than a manual install, are there any alternatives? I am interested to 
> hear how others are doing this.

I never got round to switching from using SSLMate - only $16/yr (equates to 
around £10/yr for me) for a basic (domain.tld + www.domain.tld) cert, but 
quickly gets expensive if you want more than that https://sslmate.com/pricing
They have a client script that will automatically renew and retrieve certs if 
you want to do that, or you can do it manually. TBH, once you've set up your 
services (the script will provide example config snippets on request), just 
getting updated is a matter of a couple of minutes every year. Given that it's 
only around £10, and only a couple of minutes to renew once a year, I've just 
not had any particular pressure to change.

At my last job, we used GoDaddy for certs - not sure how much was GoDaddy and 
how much was my lack of experience, but it used to seem like a right PITA at 
times. I switched to SSLMate for the (linux) systems I managed.

Oh yes, and when I have had any issues, they've been quite helpful and 
responsive.

Simon

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] à chacun son goût (was: Is it worth the effort for SPF, DMARC, DKIM, etc.?)

[Simon Hobson]

Rick Moen  wrote:

>> Regardless of the arguments for and against which have been done to
>> death for long enough, SPF did predictably break email in many ways -
>> some of which I used to use, and some which my clients used to use. 
> 
> Sounds like a problem local to you.

No, not in the least bit "local to me".  I will be generous and assume that you 
simply misunderstood what I wrote - it happens a lot :-(

Prior to SPF, it was perfectly OK to (for example) :

Have an account (lets say f...@example.com) so that fred can have an email 
address that "goes with" his website. For reasons we never understood*, Fred is 
adamant he is not prepared (even if we configure it for him) to have a second 
account in his mail client to directly collect mail from our mail server using 
POP or IMAP. He just wants mail to arrive in his inbox. So instead we simply 
forward his mail to his regular account - tends to be 
"somegibber...@btinternet.com" and things like that). Of course, some wanted 
"sales@...", "support@...", and so on as well - though mostly these clients 
were prepared to do it without forwarding to an external account.
For many years that worked just fine. ONLY when more players started 
implementing SPF did it break. We didn't change anything, others implemented 
policies explicitly designed to break it. AFAIK there is no simple way around 
that, and customers took it that our system was broken regardless of how we 
tried to explain what the problem was and ways to get around it (they still 
won't countenance adding a new account to their mail client though).

* If you ever think you understand the mindset of clients, I think the universe 
reconfigures to generate new and "more interesting" ones :D And as for the 
mindset of developers who simply couldn't or wouldn't understand the 
instruction "I will generate you a new email account login for each website**, 
DO NOT REUSE this login on other sites", perhaps I'd better not go there !
** I did rate limiting and quotas on a per-account basis (useful first line of 
defence, limits extent of the damage if a site gets hacked), and it also 
allowed me to disable an individual account (rather than a whole webserver) if 
needed.

BTW - I did try Sender Re-Writing (this was before DMARC & DKIM were popular). 
However, my technical skills are not up to writing software to do it myself. 
There was software to do it with Postfix - but it fundamentally conflicted with 
other software we were already using and we'd have had to stop using what was 
probably our most effective anti-spam measure. When I did a quick search to 
check I'd got the right name for that, I found that Microsoft supported it in 
O365 - which was a bit of a surprise.

> Possibly you wish to originate port 25 mail on IP addresses you are not 
> prepared to declare in an SPF RR for reference by SMTP receivers.

No at all, see above about assuming you simply misunderstood what I was trying 
to say.

> Like, maybe your users think it's  still 1995 and that they ought to be free 
> to originate outbound port 25 SMTP connections purporting to represent your 
> domain from arbitary, not-preplanned IP addresses at will.

Again no. It's not about who sends mail purporting to be me, it's about 
allowing me to legitimately forward mail from "some random person" to one of 
our clients - where that client just wants the email to appear in his inbox. 
Yes, I understand there's an argument that it's "not legitimate", but it was 
long established practice and it broke. And it broke in exactly the ways that 
people knew SPF would break before they implemented it.
As I said, I can't help thinking that the big players that jumped in with this 
first, considered such breakage as "a good thing" - why on earth should Fred be 
allowed to put f...@example.com on his website when he should be putting 
fred1234987234...@gmail.com on there instead.

> What I know is that all legitimate linuxmafia.com mail originates from
> my MTA's static IPv4 address, and my declaring that in an SPF RR as the
> sole legitimate origin helps others definitively detect and reject
> forgeries.  Therefore, I publish such an SPF RR, and am happy with the
> results.
> 
> You say that for some reason you cannot gain the same benefit?

I said no such thing - and now it is getting harder to assume misunderstanding.

>> In a small way, by implementing SPF yourself, you've added to the
>> support for something that broke existing LEGITIMATE mail activities. 
> 
> I doubt your premise that SPF 'breaks' anything

It breaks mail forwarding as already mentioned. It breaks mail list managers 
configured as they were mostly previously configured. There's little to argue 
there - it's even stated in the design description for SPF that these would be 
broken. For list servers, there is an argument that all of the workarounds have 
undesirable characteristics.

> and find it highly suspicious that you don't support your assertion with 
> anything even remot

Re: [DNG] Is t worth the effort for SPF?, DMARC>, DKIM?, etc

[Simon Hobson]

Rick Moen  wrote:

> My response inevitably is that I really couldn't
> care less whether they like SPF or not. ...

May I respectfully pick you up on that one.

Regardless of the arguments for and against which have been done to death for 
long enough, SPF did predictably break email in many ways - some of which I 
used to use, and some which my clients used to use. In a small way, by 
implementing SPF yourself, you've added to the support for something that broke 
existing LEGITIMATE mail activities. So your approach has a hint of "I don't do 
that, so I don't care about the people who do and now find it broken".

OK, in reality it doesn't make one jot of difference since the "big guys" had 
already taken the attitude that they don't g.a.s. about what they break for 
others, but still it's supporting something that takes away others' freedoms in 
a small way.

Hmm, didn't Devuan come into being partly due to someone pushing a policy of 
not caring what he breaks for other people ? Sorry, that was a bit below the 
belt but I hope it illustrates the issue. Luckily the breakages with email have 
(mostly) been easier to deal with than those that caused Devuan to exist.

Simon

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..devuan to the rescue? Easiest possible newbie email server setup, ideas?

[Simon Hobson]

Alessandro Vesely via Dng  wrote:

>> I have no choice over the neighbours !

> Don't buy overly cheap connections...

Doesn't matter how much you pay - unless you get an entire net-block to 
yourself then you have no control over the neighbours. Only the ISP has control 
over the neighbours.

> Another possibility to discard spammers claiming to be your domain is to set 
> SPF -all.  That, however, has other drawbacks.

I think you missed the context.
For *MY* mail server, I can ignore any SPF records etc - if the connecting 
client claims to be me then I know it's lying.

Simon

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Is t worth the effort for SPF?, DMARC>, DKIM?, etc

[Simon Hobson]

terryc  wrote:

>> You can also publish DKIM and SPF records so as to produce
>> DMARC-aligned authentication for any hosted domain.  Users won't
>> notice any difference.
> 
> Does anyone have any figures on how effective these methods are?
> It seems we get a new idea every few years and none make the slightest
> difference in spam levels. 

At blocking spam, no idea - but as you say, doesn't seem to have reduced spam 
much as there are still plenty of compromised systems that can send 
"legitimate" mail via their configured mail server.
But they are highly effective at breaking things that were once considered, and 
IMO still are, legitimate activities - such as forwarding mail from one mail 
account to another. But I suspect the big players consider that a good thing as 
it tends to make people more inclined to use their broken services.

> The only result is that there is now an industry of religious extremism
> in "blacklisting" sites that don't follow their desired implementation.

Agreed

>> Currently, the RFC allows anything in the HELO name.
> 
> Brings back memories of my first linux mailer SMTP, where it came with
> teo alternative sets of greetings. I always preferred the second option
> of;
> "Who are you going to pretend to be today" and the response
> "Thrilled beyond bladder control to meet you"
> and so on.

That's great :D
I just might borrow those.

Simon

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..devuan to the rescue? Easiest possible newbie email server setup, ideas?

[Simon Hobson]

Ian Zimmerman  wrote:

>> You mean, like in the web hosting days before hostname headers where
>> you needed a different IP address for each hosted domain name ? That's
>> very 20th century and not a luxury most of us have.
> 
> FWIW, Linode (where my sole server is hosted) gives me a /64 IPv6 block
> for free. That's 2^64 addresses. And the same with our home ISP, in case
> I felt like violating the terms and running a server.

Yeah, I can have a /56 or /48 for IPv6. How many IPv4 addresses do you have 
since much of the world is still IPv4 ?

Simon
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..devuan to the rescue? Easiest possible newbie email server setup, ideas?

[Simon Hobson]

Alessandro Vesely via Dng  wrote:

>> IIRC the specific complaint wasn't that they checked for rDNS, but that they 
>> matched it against the domain of the sender. That makes no sense at all, it 
>> prevents running more than one domain on one mail server.

> Why would it?  A configurable mail server, Courier-MTA for example, lets you 
> use multiple domains and multiple IPs.

You mean, like in the web hosting days before hostname headers where you needed 
a different IP address for each hosted domain name ? That's very 20th century 
and not a luxury most of us have.

> However, unless you send many thousands messages per day, I would suggest to 
> stick to one domain name and one outgoing IP address.

There's no problem running mail for multiple domain names through one mail 
server, as you say, just a matter of setting the MX records for each domain and 
configuring the server. But as I recall how I read the message that kicked this 
subthread off, a couple of ISPs were checking the sender domain of the email 
against teh DNS name for the mail server - so for example if I were to use one 
of my other email addresses, they would reject mail because the sender domain 
(i.e. not thehobsons.co.uk) didn't match the domain name of the mail server in 
the DNS (patsy.thehhobsons.co.uk) -that's just plain dumb.

> And it is key to get an IP address without poorly reputed neighbors —check 
> talosintelligence.com.

I have no choice over the neighbours !

> As Mark said, it does make deliverability easier to send via one established 
> SMTP server.

It depends on your criteria. In my experience, it can easily be the reverse - 
especially if that email server isn't really really tight on controlling what 
it's users send.

>> I also use lack of rDNS as a check. I also check it for obvious 
>> misconfigurations like (from memory) : it's an IP literal (not allowed by 
>> RFC),
> 
> Currently, the RFC allows anything in the HELO name.

Without looking it up, I'm sure there are some constraints. In any case, there 
are some thing it makes sense to block - so-one else should be running a mail 
server and claiming to be in my domain, stuff like that. Some basic protocol 
checks block a good proportion of spam - and very cheaply in terms of resources 
needed.

Simon

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..devuan to the rescue? Easiest possible newbie email server setup, ideas?

[Simon Hobson]

Marjorie Roome via Dng  wrote:

> I also end up rejecting a lot of spam because it lacks a reverse hostname 
> (it's easily the largest category).
> So it's not just a few such as ntlworld and gmx that check this.

IIRC the specific complaint wasn't that they checked for rDNS, but that they 
matched it against the domain of the sender. That makes no sense at all, it 
prevents running more than one domain on one mail server.

I also use lack of rDNS as a check. I also check it for obvious 
misconfigurations like (from memory) : it's an IP literal (not allowed by RFC), 
it's not one of my domains, the domain actually exists.
But one thing I don't check is that the rDNS matches the name given by the 
server in it's greeting - that just gets too many rejections because to many 
supposedly professional IT people can't get basics right. And I don't just mean 
"little guys", some of the problems I've seen with DNS and mail servers have 
been from larger outfits where I know they employ sizeable IT departments.



Rick Moen  wrote:

> :r! dig -t txt _dmarc.linuxmafia.com +short
> "DMARC: tragically misdesigned since 2012.  Check our SPF RR, instead."

Thank you for brightening my day :-)



On 26 Sep 2020, at 04:53, Mark Rousell  wrote:

> Ah, thanks. It does make deliverability easier to send via an established 
> SMTP server such an one's ISP's server.

But then you :

a) lose all visibility of what happens to your mail
One of the reasons I use my own mail server is because I can then see exactly 
what's happening to my mail. Especially if it's not getting delivered - which 
these days doesn't generally seem to be a problem, even for AOL !
It also means I have evidence from my logs. On a number of occasions I've used 
this along the lines of "as per  which was delivered to your 
mailserver on " when dealing with people who have "conveniently 
lost" previous communications.

b) are reliant on your ISP being capable of running a mail server reliably.
I don't think I'm alone in finding ISP mail server offerings to "have 
shortcomings". I've personally lost mail due to incompetent ISPs.
As previously mentioned, unless you are expecting an email that doesn't arrive, 
you don't know you've lost it. I went through a phase where my ISP was losing 
mail, but only intermittently. It was only when I could pinpoint something 
missing, and the sender was tech savvy enough to be able to give me their 
server logs, did my ISP finally consider I had a complaint to investigate - 
they then went and changed my settings in their control panel to wrong 
settings, and lost mail that they'd had queued on the wrong server for some 
time (triggered delivery without any notice, but from the wrong server and my 
server rejected them as it only allowed mail specific servers (the ones they 
listed as inbound relays)).


But then, having run mail servers for some years now, I can really really 
understand the desire to make it an SEP (Someone Else's Problem) !


Simon

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OT? ..devuan to the rescue? Easiest possible newbie email server setup, ideas?

[Simon Hobson]

Mark Rousell  wrote:

>> But once you accept a
>> message with a success status after the DATA stage, you are obliged to
>> either really deliver it or else bounce it back. It is not acceptable to
>> send messages down a "black hole".

> This *should* not be acceptable (and it's very annoying if you are a 
> legitimate sender who has his email swallowed like this) but this method 
> works well for the big mail service providers, who all seem to do it.

Yes, it's the default because it's easy to do - so if you can get away with it 
then why put the effort into doing it right ?
While all the software bits are there (or would be trivial for the big players 
to write if they didn't already exist), the main reason for "accept then bin" 
operation is scalability. Accepting mail is fairly cheap - a handshake and some 
preliminary (cheap) checks, then pour a data stream into a file, job done. So 
scaling mail acceptance is easy and cheap to do.
Doing full malware & spam filtering is resource intensive. If you want to do it 
in real-time before deciding whether to accept a message or not, then you need 
to scale your resources for peak inbound mail rates. But if you do "accept then 
bin", you can scale your resources for more average rates and just let messages 
sit in a queue for a few minutes when things are really busy. Given the 
resources available to MS and Google (to name just two), that's not really a 
valid excuse - but I bet it's one of the ones they use.

As an aside, many of the "how to setup Postfix with spam/AV scanning" all do 
the two postfix instance setup - where one instance accept the mail, then pipes 
the messages through Amavis with SMTP, and then the second instance manages it 
into mailboxes.

> Many of their users don't even care that, as a result, they are missing mail 
> from legitimate contact and customers.
> 
> You'd think that customer pressure would force the service providers to act 
> more sensibly but because the customers don't *see* the problem they don't 
> care about it, even small business customers who lose business as a result.

That's the problem - it's mostly invisible. Take the likely scenario - customer 
emails to say "I'd like to spend money with you on ..." and gets no answer. 
Unless you really have a very compelling offering, the prospective customer 
just goes off elsewhere and you never know that you've lost business.
I'm sure that a great many businesses would complain, and loudly, if they 
actually knew.

One thing I can be sure of, if Royal Mail (or whoever your local postal service 
is) "just binned" anything that their algorithms decided you weren't likely to 
want, there would be more than just strong words about it. In many 
jurisdictions, it's a criminal offence to interfere with delivery of a mail 
item.


At a previous job I had responsibility for running a mail server for our 
clients. Initially it was a thrown together quickly system 
(Debian/Postfix/PostfixAdmin/Courier) to replace an iMail system running on 
Windows NT that a) fell over regularly, and b) had a huge problem with spam. 
That iteration ran for years, until I replaced it with an upgraded one - and I 
put in effort to reject spam BEFORE accepting a message. As far as I concerned, 
if your mail server responds with "OK, I've accepted that" at the end of a 
message then you have only one choice - to deliver it. I made a point of 
pointing out that our mail service would not fail to deliver a message that had 
been accepted for delivery.
I duplicated the same setup at home for my own server.

As part of the rundown of services before I was made redundant, my employer was 
busy selling people onto O365 - and at no time would the customer be told about 
O365's dirty secret, that it will throw away some of your main and you'll never 
know unless the sender contacts you via a different means. Clients were also 
told that there was no GDPR problem for them to consider at all - even though 
anyone with 2 brain cells to rub together can explain the many ways in which 
O365 is fundamentally incompatible with GDPR, but that's a different thread 
altogether.

Simon

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] How to mount NTFS

[Simon Hobson]

Haines Brown  wrote:

> I left the drive NTFS because I wanted easy access to the drive for folks 
> (granschildren) who do not run Linux. 
> 
> Othersie I prefer ext4. When you say NTFS is slower, to you mean three times 
> slower (which I am experiencing) or a bit slower?

In my experience, as already said, very significantly slower - so yes, could 
easily be the /3 performance hit you've observed.

I have a suggestion ...
Create a small partition in NTFS or Fat, and put some files on there saying 
what else is on the drive - and some hints on how to access it. The way things 
are, it is highly unlikely that none of the intended recipients would not know 
anyone with the skills and ability to read the backups - as long as they (your 
descendants) actually know what to ask.
So yes, if you just have an EXT4 partition, they'll have no idea - if they get 
a small disk with notes saying "the files are on another partition - find 
someone who knows Linux or [list of other OSs that handle EXT4], or find 
software for your Windows machine that can handle it (it does exist), then 
they'll have the basic information to get at your files.

PS - yes, I second the suggestion for rsync.

Simon
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] End-end encryption (was: Zoom? Rather not...)

[Simon Hobson]

marc...@welz.org.za wrote:

> Some people are going to say "not possible, the call is
> end-to-end encrypted". Actually no. Illustrative example: The
> intercept reported that zoom claimed end-to-end encryption,
> but instead had one shared key, and used ECB (a really poor
> way of using a cypher). That is why it works so well, as a
> single lost packet doesn't garble the rest of the stream. More
> importantly, unlike Balsamic Vinegar or Zero Percent Fat,
> there is little enforcement of what these terms mean, and
> governments are keen to weaken encryption further.

In Zoom's case, I believe it did in fact refer to "encrypted from user to data 
centre, then encrypted from data centre to other user" with an unencrypted bit 
in the middle. You could still argue semantics and say that it is encrypted at 
both ends ...
Now for WhatsApp, things are a little trickier. From what I read it is 
genuinely encrypted from one user end all the way to the other user - good 
right ? But at each end everything is stored unencrypted. But that's no 
problem, both IOS and Android enforce sandboxed storage on Apps so the 
unencrypted chats etc are safe ?
Well what Faceborg did was to subtly change things so that both WhatsApp and 
Facebook clients use the same sandboxed storage - meaning that the Faceborg 
client has free access to your WhatsApp chats - and therefore Faceborg itself 
has free access should it choose to take a peek.
And of course, we all trust Faceborg to to abuse such access don't we, after 
all they have no track record whatsoever of dodgy dealing or ignoring the law 
do they ?

Simon

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Zoom?

[Simon Hobson]

Steve Litt  wrote:
> 
> On Wed, 5 Aug 2020 08:28:12 +1000
> Ozi Traveller via Dng  wrote:
> 
>> Yes that is the reason for teams.
>  
> 
> What do  you mean by "that"?

He'd be referring to my comment :
>>> That's fine if anyone you want to chat with also uses Teams.

Presumably he's switching to Teams because the people he needs to deal with 
have switched to it. That's the problem - just because you or I don't want to 
use a particular option, doesn't mean we can avoid doing so if we have a need 
to deal with people and they have made that decision.
At the day job we are starting to use Teams. I can see a lot going for it, but 
it also looks like more of the same slow, clumsy, eye candy we've come to 
expect from MS.

Simon

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Privacy and large public, yet privately owned, service providers (was: Re: Zoom?)

[Simon Hobson]

Martin Steigerwald  wrote:

> Unfortunately we have Office 365 at work.

As do we - but I do know that our infrastructure is all on-premises for 
security reasons, and my employer is big enough to put the resources into 
running it properly.
It's been a marvellous play by MS - cobbling together a few disparate products 
and making them "just good enough" for corporates to not reject them, while 
providing the "integration" (which really means vendor lock in and competitor 
exclusion) to make it an easy sell to the IT people who need to make it run. I 
say "cobble together" and "just good enough" because that's just what it fells 
like having been using Macs for the last  decades and now having to use 
Windoze. Little things like Outlook, despite having been part of "the package" 
for a long time still has completely different keyboard shortcuts to the other 
programs - Apple went all out for consistency back in 1984, Microsoft don't 
seem to have heard of it.

Luckily we're still on W7 so not a completely alien landscape - but we're due 
to go to W10 in the not too distant future.


> And there are  several data / privacy protection officials who say it is 
> legally impossible to use Microsoft Teams and Co in Germany.

It is. It is not possible to use O365 and comply with GDPR - it just hasn't 
been blown out of the water in court yet.
I know that at a previous employer (small It services business), "we" (doesn't 
include me) were busy switching users from our in-house mail to O365 - and 
stating quite clearly that it's all OK as you can select to store you data in 
an EU datacentre and the contract is with Microsoft Ireland. The business 
between Microsoft and the FBI, and their actions as soon as the CLOUD act was 
passed prove that Microsoft in the US has access to data held in datacentres in 
Ireland and supposedly only accessible to Microsoft Ireland. If is the 
separation was as claimed, all the access to data is controlled by systems 
under US control.
Of course, small business don't have the resources to look into this sort of 
thing - they rely on what their suppliers tell them, even if it's a pack of 
half-truths.


> And then Max Schrems and his team at noyb.eu convinced the highest 
> European court to finally kick Privacy Shield.

Yes, it will be interesting to see what sort of kludge they come up with next - 
there's a lot riding on not killing trans-Atlantic data traffic.

Don't forget that Privacy Sh^H^HFig Leaf was a kludge to allow business as 
usual when Safe harbour was blown out of the water. Everyone could see it would 
also be blown away, but there is too much riding on business as usual to allow 
such details as fundamental incompatibility between the two sets of law to get 
in the way.

Simon

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Zoom?

[Simon Hobson]

Haines Brown  wrote:

> I've been relying on zoom on a laptop runnding debian. But there's a 
> problem with it and I want to install zoom on beowulf 3. 
> 
> But there's no zoom in the beowulf repository. Do I have to download 
> debian's zoom .deb?

Or download direct from Zoom's website.

I recall trying it out not long ago, I "wasn't impressed" with some of the 
dependencies - it seems to pull in a lot of dubious looking stuff.


Ozi Traveller via Dng  wrote:

> I've switched to teams. 

That's fine if anyone you want to chat with also uses Teams.


Simon

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Problem with DHCP during boot

[Simon Hobson]

Keeping it on-list


Rod Rodolico  wrote:

> Stupid question, but do you have a static MAC address assigned to your
> virtual? My dhcp server reads the MAC, then determines what IP to give
> it. Xen gives random MAC addresses if you do not assign one. Assuming
> KVM does it also.
> 
> Xen has the block 00:16:3e:* reserved for it, so I wrote a little Perl
> script to randomly generate one every time I build a virtual, since the
> MAC should be unique in a network.

Yes, I've given it a fixed MAC, and I've set it's lease as reserved on the 
server. BTW, if the 7th bit is set, then that signifies locally managed MAC 
addresses - so mine are now 02:xx:xx:xx:xx:xx.

The problem is triggered by a change in DCHP Client behaviour. It used to be 
that the ISC client did **NOT** send a Client-ID by default - which meant 
various problems when multi-booting with other OSs that send the hardware 
address by default.
Now the ISC client sends a DUID-LLT value by default. This is a combination of 
hardware address and time, the theory being that it remains constant even if 
the MAC address changes. If there's a Client-ID then the server uses this as 
the primary lease key and does not consider the hardware address at all.

The behaviour I've been seeing is consistent with the DHCP client being started 
before it's local lease database is available - and so it has no access to the 
stored DUID. As a result, it generates a new one, and obviously the time will 
be different to the previous ones - hence as far as the server is concerned, on 
each boot it's a different client and gets a different address.
Manually dropping and restarting the interface means the client gets access to 
it's lease database, so it uses the stored DUID, and so it gets the reserved 
address.

I've been trying to debug the issue by adding logging to both 
/etc/network/interfaces and /etc/init.d/network - try doing that with SystemD 
:D As soon as I tried that, on the next boot it worked as it should :-/ Then it 
didn't work on the next boot.
I can't help thinking that something is bringing up eth0 before the disk 
filesystems are mounted (i.e. while it's still running from it's initramfs) - 
but I just can't find any evidence of that other than the interface already 
being up when /etc/init.d/networking is run to bring up networking.

I'll have another go at it when I next get a bit of spare time.

Simon

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Problem with DHCP during boot

[Simon Hobson]

Stephane Ascoet via Dng  wrote:

>> I think I'll ask the same question over at the ISC DHCP list, we're a 
>> friendly bunch over there, but it's more an OS question than a DHCP one. 
>> Still, there's a range of experience, so someone else might have hit this 
>> and know the answer.

> Hi, so, with this friendly touch with them at ISC, if you could ask about 
> resolution of  and 
> ...

Have you tried asking on the ISC DHCP Users mailing list ? The above are Debian 
bug tracker links - the maintainers of the Debian packaging may or may not be 
on the ISC ML (I haven't looked), and I think it's fairly certain that most of 
the people who are on the ML won't be checking for Debian bugs.
dhcp-users mailing list https://lists.isc.org/mailman/listinfo/dhcp-users

Mind you, the first of those does seem "rather old" !


Simon

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Problem with DHCP during boot

[Simon Hobson]

aitor_czr  wrote:

> Florian Zieboll wrote:
>>> 

>> Although I am not doing IPv6 networking myself, I suppose searching the DNG 
>> list's archive for the ifup boot delay issue might bring up relevant 
>> information.

> Further discussion here:
> 
> https://lists.dyne.org/lurker/search/20380101.00.0...@ifupdown.es.html

Thanks.

Ah, I should have said this is IPv4 only, this looks like a change in the ISC 
client to now send a Client-ID in the form of a DUID (DUID-LLT by default).

The above references seem to be issues with when/whether interfaces are brought 
up when something is unplugged. In this case, it's clear that the DHCP client 
is being run by "something" prior to bringing up networking - so when the 
"real" networking is invoked, eth0 is already up using the wrong config. I just 
can't see where that's happening.

I think I'll ask the same question over at the ISC DHCP list, we're a friendly 
bunch over there, but it's more an OS question than a DHCP one. Still, there's 
a range of experience, so someone else might have hit this and know the answer.

Simon


As an aside, I also found out that MongoDB no longer ships with a sysV init 
script in it's deb files.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Problem with DHCP during boot

[Simon Hobson]

I've got a VM running Devuan Beowulf that was upgraded from Debian Wheezy (via 
Devuan Ascii). The problem I have is that it keeps getting different IP 
addresses during boot, never the one the DHCP server is configured (reserved 
lease) to give it. On tracing packets, I see that it's using a different DUID 
value during boot than it uses if I manually take the interface down and back 
up (ifdown eth0;ifup eth0 when the system is running). Also, during boot I see 
the message "Configuring network interfaces...ifup: interface eth0 already 
configured".

This suggests to me that something is bringing up the interface early during 
boot, using a different or non-existant DHCP Client config. I suspect 
non-existant since the address leased changes every boot which suggests a 
different DUID. I just can't see what/where the interface is being brought up .


From my packet trace, I'm seeing the client sending :
Option: (61) Client identifier
Length: 19
IAID: 3e10c4f2
DUID type: link-layer address plus time (1)
Hardware type: Ethernet (1)
Time: 648121466
Link-layer address: 02:16:3e:10:c4:f2

Time: 648121466 is what I consistently get bringing up the interface after 
booting. During boot I get different Time values - so the DUID is different, so 
the DHCP server treats it as a different client.
Looking at two different packet traces, I see values of 648143408 and 
648121466, puts them about 75 minutes apart which ties in with the timestamps 
of my packet capture files.

Can anyone give me any hint as to what is bringing up the network before it is 
supposed to be ?

Simon

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Boot hangs with usb disk active in fstab

[Simon Hobson]

J. Fahrner via Dng  wrote:

> I don't see why this parameter is so important. When I read the description, 
> this is the delay for scanning usb devices after power up. But as you can see 
> in the logs, the device is responding and telling its characteristics. Only 
> mounting the filesystem fails.

As I've read the thread, the delay is between querying the USB bus for devices 
and trying to read from them. In your case, the device is been seen on the bus, 
but the mount fails - one possible cause of that is that the USB bridge device 
and/or disk are not ready in time, i.e. that the chippery and/or disk between 
them are not read to read data within 5s (if that's the default) of the devices 
being enumerated.
So changing this parameter is to see if giving a longer time between 
enumerating the devices on the bus (at which point, the chippery and disk 
should initialise and spin up) and actually trying to read form the disk. If it 
does, great; if it doesn't then there's a different problem.

> A smaller disk is no option, since this is my media server at home. It is 
> filled with 66%.

I think the idea was simply to try a smaller disk and see if that works. It's 
all in an effort to narrow down the list of possible causes - e.g. if it still 
won't mount then it being a big disk isn't the problem; if it does mount then 
at least you know it's not the USB chippery in the drive case.
At present, there are a lot of possible causes, which makes fixing the problem 
tricky.


Simon

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Debian abandons LSB

[Simon Hobson]

Alessandro Vesely via Dng  wrote:

> https://en.wikipedia.org/wiki/Linux_Standard_Base#Limitations_on_Debian

Ah, that helps. I was confusing LSB with FSH and LSB headers - not that I ever 
followed such detail closely.

>> What's left in Debian are bits that are actually used by some programs.
> 
> Such as the LSB headers in init scripts?
> 
> Some SysV init maintainers have very strict opinions on those headers,
> considered a language for the insserv "compiler".  They horrified at the idea
> that a sysadmin could still manually number some links in rc?.d, thereby
> rejecting the idea of stable renumbering in order to keep existing order where
> possible (fix-init).

And contributing to the "SysVInit is bad - it's scripts are too long" 
"argument" from certain quarters.

Simon

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Debian abandons LSB

[Simon Hobson]

While upgrading a system to Beowulf, I noticed this in the changelogs.
Is this one of those "it was fizzling out anyway so no big deal" things, or 
another policy change by Debian ? Not really bothered, just curious.

> lsb (9.20150826) unstable; urgency=low
> 
>   This update drops all lsb-* compatibility packages, and is therefore an
>   abandon of the pursuit of LSB compatibility for Debian. Only lsb-release and
>   lsb-base are kept as they continue to be used throughout the archive.

Simon

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Current state of VPN software ?

[Simon Hobson]

Dr. Nikolaus Klepp  wrote:

> vpn easiest way: sshuttle
> otherwise just use ssh + vnc (on the mac)

Thanks - but not really what I'm looking for.

Well something I could do today (or at least, as soon as I pop round to put the 
Pi in place) is to use SSH and tunnel a local port to the remote machine. Done 
that lots of times in the past.
I'd rather route the subnets through a tunnel - there's other uses I have for 
it as well. Plus, it's just sooo much more convenient to have routed IP.

VNC not needed, Macs have had an inbuilt screen sharing (based on VNC I think) 
for a long time now.

Simon

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Current state of VPN software ?

[Simon Hobson]

It's been a while since I last did anything with VPNs on Linux, and I recall 
there being 3 options, some of which were "less well supported" than others. 
I'm looking to setup a site-site tunnel so I can remotely access stuff at mum's 
(she's in isolation because of this Covid 19 stuff) and using remote desktop 
control, connect her Mac to a video call.

So what's the state of play in the VPN on Linux world - both ends would be 
running Devuan (one end an AMD64 VM, the other end rPi) ? Last thing I used was 
OpenVPN which AIUI is completely non-interoperable with anything else, while 
FreeSwan and OpenSwan were having a bun fight.

Simon

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] What to do with an inode?

[Simon Hobson]

Hendrik Boom  wrote:

> On Mon, Mar 30, 2020 at 03:18:45PM +, aitor_czr wrote:
>> 
>> $ ls --inode --directory "/"
>> 
>> 2 /
> 
> Is there anything I can do with an inode except check file identity within
> a filesystem?

You can use it as a search condition for find using '-inum n'
Other than that, my quick search suggested there aren't any useful things you 
can do with it - or at least nothing that's not easier to do by just looking up 
a name for it and working with a normal directory entry.

I did see some search results related to file with no directory entry, but the 
inode staying in existence due to the file being open. As in, "I want to create 
a directory entry pointing to a specific inode to rescue the file so it doesn't 
disappear when closed". I didn't actually look at any of these though.

Simon

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] What can even possibly go wrong?

[Simon Hobson]

Dan Purgert  wrote:

> It's certainly useful in a "campus" environment, where you're quite
> likely at a different computer all the time (i.e. grabbing whatever is
> free in the computer lab to print your final paper).

Isn't the answer there to mount your home dir off it's server on whatever 
machine you are using ? Something perfectly doable since ... err ... long 
before I ever got involved with any unix[like] system.

Simon

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] why is polkit needed?

[Simon Hobson]

tekHedd  wrote:

> Surely it is time to boil down the dbus/polkit requirements and and start 
> over. Preferably with sane limitations on scope and configuration mechanisms. 
> I mean, I'm just thinking out loud here something that I've been thinking for 
> about 6 months.

I applaud your thinking, but alas I fear the result may be https://xkcd.com/927/


> Also, who has time to rewrite polkit and dbus from scratch?

Alas I have neither the time nor skills to help with such a project :-(

Simon

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Question: Why does "mkdir -p" produce unexpected file permissions and group

[Simon Hobson]

Stefan Krusche  wrote:

> What is the difference between "below /usr/local"
> and "in /usr/local" for directory "/usr/local/something"?! (as referred
> to in this section of the debian policy.)

AIUI, "in" means those items that are directly within the directory, while 
"below" means those items within other directories.
So /usr/local/foo is "in" /usr/local and /usr/local/something/foo is "below" 
/usr/local. I'm not sure which designation /usr/local/something (being a 
directory rather than a file) comes under.

Simon

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Again, again: DMARC is a no-win problem for mailing lists (was: Can we fix this DMARC thing?)

[Simon Hobson]

Steve Litt  wrote:

> ... we could at least
> change the munge string from:
> 
> Firstname Lastname via Dng 
> 
> to: 
> 
> GOES TO DNG (IRT Firstname Lastname)
> 
> So when you do "return to sender" and it crazily puts
> dng@lists.dyne.org in the To field, at least that To field won't be
> disguised as the user.

Quick question ...
Does your MUA show the full address, or does it follow the MS rule of actively 
hiding the actual address and only showing the name part ?
I am now forced to use Outlook for mail at work, and it's a pile of steaming 
manure in many respects. Prior to starting work, I had to have some email 
exchanges with my manager so his outlook has cached both my personal and work 
addresses. Since Outlook makes it hard to see the email address that's behind 
the name, there are times when he's sent work email to my home address.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Identifying or rsetting a microsd card

[Simon Hobson]

marc  wrote:
> 

> I wonder if writing 0xff instead of 0x00 is kinder to flash
> media. In particular, if the controller is dumb/smart enough
> to only erase, not write... 

I would imagine there's a command you can send to the card which tells it to 
bulk-erase itself. Function in one of the disk utils ?

Simon

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Identifying or rsetting a microsd card

[Simon Hobson]

>>> Hm, dd if=/dev/zero of=/dev/sdb bs=1M count=1
>> 
>> Yes, that will clear it out.  But what file system is customarily on
>a new
>> 16G microsd card?  And does that fs really need everything cleared
>out?
>
>No, that will not wipe the GPT or it's backup.

Ah, but zero the whole disk and it will 

dd if=/dev/zero of=/dev/sdb bs=1M

It'll use one write cycle on the media.

Simon


-- 
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Insane defaults on Raspberry Pi images - How to fix corruption/dataloss

[Simon Hobson]

Jim Jackson  wrote:

> (*) These pi's are a lot more powerfull than the Sun Sparc servers we had 
> NFS serving user data to 60+ workstations back in the 00's :-)

Ah yes, to think that many of us routinely carry around in our pockets more 
storage, RAM, and CPU capacity than we could have dreamed of having access to 
back when I got into IT. Cue obligatory Four Yorkshiremen sketch :D
https://www.youtube.com/watch?v=VKHFZBUTA4k

If you haven't seen this before, it's worth waiting for the punchline ...

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] IBM Gives Away PowerPC; Goes Open Source

[Simon Hobson]

Didier Kryn  wrote:

> Therefore it means IBM doesn't care anymore in PowerPc arch ... That's what I 
> fear, actually.

I don't think it means that. It's clear that PowerPC is stuck as a niche 
architecture. The only way out of that is to get lots of people using it - and 
making it freely available is one way towards that. You only need to look at a 
few examples to see that :

USB vs FireWire. Firewire was very significantly better in many respects than 
USB, but it was expensive to implement because Apple were greedy over 
royalties. The inferior USB was really cheap to implement and took over.

ARM. They licensed it widely for modest amounts, and it's been widely 
implemented instead of other architectures.

For IBM, it could be a shrewd move to get more people using the platform, and 
thus boost it's popularity, and thus boost both the availability of hardware 
and choice of software to run on it. The Intel approach is to try and have all 
of the cake; this could be a move to make the cake much bigger, and thus make a 
slice of it bigger.
IFF it works, they'll significantly expand the PowerPC market - and while 
they'll have a smaller share of it, they'll actually make more money.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] linux-image-4.9.0-9-amd64 update breaks networking

[Simon Hobson]

Chris Richmond  wrote:

> Aug  4 18:33:15 teton dhclient[3755]: Listening on LPF/eth1/00:1c:c0:e1:d0:ff
> Aug  4 18:33:15 teton dhclient[3755]: Sending on   LPF/eth1/00:1c:c0:e1:d0:ff
> Aug  4 18:33:15 teton dhclient[3755]: Sending on   Socket/fallback
> Aug  4 18:33:15 teton dhclient[3755]: DHCPDISCOVER on eth1 to 255.255.255.255 
> port 67 interval 5
> Aug  4 18:33:20 teton dhclient[3755]: DHCPDISCOVER on eth1 to 255.255.255.255 
> port 67 interval 6
> Aug  4 18:33:26 teton dhclient[3755]: DHCPDISCOVER on eth1 to 255.255.255.255 
> port 67 interval 14
> Aug  4 18:33:40 teton dhclient[3755]: DHCPDISCOVER on eth1 to 255.255.255.255 
> port 67 interval 13
> Aug  4 18:33:53 teton dhclient[3755]: DHCPDISCOVER on eth1 to 255.255.255.255 
> port 67 interval 7
> Aug  4 18:34:00 teton dhclient[3755]: DHCPDISCOVER on eth1 to 255.255.255.255 
> port 67 interval 8
> Aug  4 18:34:08 teton dhclient[3755]: DHCPDISCOVER on eth1 to 255.255.255.255 
> port 67 interval 8
> Aug  4 18:34:16 teton dhclient[3755]: No DHCPOFFERS received.

Right, that gives a pointer to where the problem lies - but unfortunately there 
are mny reasons this situation can occur.

It would be useful to run a packet capture (tshark, etc) and see if any replies 
are actually received from the ISP ? If they are, then that rules out one class 
of problems - it means that the DHCP packets are getting to the ISP and being 
answered.
If you see no replies, then the the DHCP packets either aren't getting out, or 
the replies aren't getting back.

Then it's a case of looking for differences in the environment - in particular, 
interface state and any filters applied. Specifically, has anything changed in 
the filtering setup between the two kernels ?
IIRC there are changes happening to deprecate/remove netfilter and replace it 
with something else - but I don't know when that has happened/is happening in 
terms of kernel version numbers.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Identifying an installed physical hard drive without damage

[Simon Hobson]

Miles Fidelman  wrote:

> ... then see which drive's lights flash a lot (if the drive has a light).

Ah yes, those were the days .
I can only assume that they were dropped to save money - and it's really 
annoying when trying to do things like this (figure out which drive is which). 
I've noted that on servers I've worked with, the activity (and fault) LEDs are 
on the [SCSI|SATA|SAS] backplane - using light pipes to make them appear on the 
front of the caddy.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] reinstalling GRUB2

[Simon Hobson]

Haines Brown  wrote:

> I tried the chroot method, but with little luck.
...
># chroot /sysroot 
> 
># grub-install /dev/sdb
>bash grub-install: command not found
> 
># ls -la /usr/sbin | grep grub-install
>-rwxr-xr-x 1 root root 102046 Oct 28 2018 grub-install
> 
># /usr/sbin/grub-install /dev/sdb
># bash: /usr/sbin/grub-install: No such file or directory
> 
> At my wits end I remove and reinstall grub2-common. Did not help.

Sorry, it's outside my knowledge envelope. I know the steps do work as I've 
done them several times in the past. I don't know what the requirements are in 
terms of compatibility between the linux kernel that's booted and the "broken" 
system that you chroot to - are they the same architecture you are using ?
Also, I take it you mounted all the directories (/proc, /dev, etc) ?

In the back of my mind is whether the error message is a result of a lower 
level issue - eg a mismatch between kernel and system.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] reinstalling GRUB2

[Simon Hobson]

Steve Litt  wrote:

> Simon Hobson  wrote:

>> 1) use grub rescue cd (which you can put on a USB stick). Then fairly
>> easy to sort out by picking the right menu options.
> 
> Do you mean:
> 
> * Super Grub2 Disk (https://sourceforge.net/projects/supergrub2/)
> * boot-repair-disk (https://sourceforge.net/p/boot-repair-cd/home/Home/)
> * System Rescue CD (http://www.system-rescue-cd.org/)
> * GrubEFIReinstall (https://wiki.debian.org/GrubEFIReinstall)
> * Ultimate Boot CD (http://www.ultimatebootcd.com/)

The first one, SuperGrub2 - more details at https://www.supergrubdisk.org
And step-by-step guide at 
https://www.supergrubdisk.org/wizard-restore-grub-with-super-grub2-disk/

I suspect the others would also be suitable, but not ones I've used (for this)


fsmithred via Dng  wrote:
> Steve Litt wrote:
>> Simon Hobson  wrote:
> 
>>> 
>>> 2) use these incantations, lifted from a post elsewhere :
>>> 
>>> mkdir /sysroot
>>> mount /dev/your-root-dev /sysroot
>>> mount /dev/your-boot-dev /sysroot/boot
>>> mount --bind /dev /sysroot/dev
>>> mount --bind /sys /sysroot/sys
>>> mount --bind /proc /sysroot/proc
>>> mount --bind /run /sysroot/run (recommended if you are using systemd)
>>> chroot /sysroot
>>> grub-install /dev/your-grub-boot-device (may be grub2-install on some
>>> distro)
>> *Exactly* what do you mean by "your-grub-boot-device"? Does it vary
>> depending on MBR vs UEFI?
> 
> Yes, it varies depending on BIOS vs. UEFI boot. For bios boot, the grub boot 
> device is the drive whose mbr you want to use, like /dev/sda or /dev/sdb.
> 
> For UEFI, you don't name the device. Grub knows to put the bootloader in the 
> efi partition. In that case, an extra step above would be to mount the efi 
> partition to /sysroot/boot/efi
> 
>> So now you've installed Grub(2), but then how do you configure grub?
> 
> While you are still in the chroot, run:
> 
> update-grub
> 
> And that will make a new boot menu.

Beat me to it ;-)
This option will re-install Grub as long as you can boot the system from any 
disk containing a vaguely similar Linux - when you chroot you'll be using the 
tools/executables/etc from your "broken" system while running the kernel from 
your recovery system.

So lets say you can boot a system from sda, and your "broken" one is currently 
showing as sdb - with boot as sdb1 and root as sdb2. the relevant lines from 
above would then become :
mount /dev/sdb2 /sysroot
mount /dev/sdb1 /sysroot/boot
...
grub-install /dev/sdb

And as fsmithred says, you can add update-grub to update the menu - this will 
work just as if you'd really booted from sdb.


As to which method is "best", well that's a case of "horses for courses"* I've 
used both methods in the past (not for some time though). The first method is 
providing the bootable system and providing some assistance with the second 
method - probing disks, creating (IIRC) the chroot environment, etc. If you are 
able to boot the system then the second method is just a few commands (which 
you can do remotely, eg via SSH, if required); if you can't already boot the 
system at all then you'll need the boot disk to get it running.

* A phrase meaning to pick the tool best suited for the job. Literally it's 
referring to the fact that different race horses will perform best at different 
courses (or under different conditions) so you pick the one that's best suited 
for the course/conditions.
https://en.wiktionary.org/wiki/horses_for_courses

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] reinstalling GRUB2

[Simon Hobson]

I see two other ways to make this easy, both of which have worked for me in the 
past  :

1) use grub rescue cd (which you can put on a USB stick). Then fairly easy to 
sort out by picking the right menu options.

2) use these incantations, lifted from a post elsewhere :

mkdir /sysroot
mount /dev/your-root-dev /sysroot
mount /dev/your-boot-dev /sysroot/boot
mount --bind /dev /sysroot/dev
mount --bind /sys /sysroot/sys
mount --bind /proc /sysroot/proc
mount --bind /run /sysroot/run (recommended if you are using systemd)
chroot /sysroot
grub-install /dev/your-grub-boot-device (may be grub2-install on some distro)
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Cease battling each other in e-mail (was: Of confidence and support and the future of Devuan.)

[Simon Hobson]

I've been lurking and resisting from posting, largely because ... I'm the last 
person to be telling people how to communicate in a friendly manner. I'm 
autistic, and one of the traits I get from that is the tendency to completely 
miss the subtleties of interpersonal communications, and to speak (write) in a 
fairly blunt manner. Thus I find I can quite easily turn a normal situation 
into a complete sh*tstorm without any effort at all :-(

But speaking as someone who's done practical jokes that weren't well received, 
and made cockups when administering systems, this recent sh*tstorm just isn't 
fair to anyone involved or productive to the project.

As Rick quite correctly notes :

Rick Moen  wrote:

> The Jenkins server thing?  That was an annoying technical failure, but
> did not in any way justify your firebreathing public and private
> e-mails.  Treat it as a minor organisational-process bobble that took 
> down an important system.  Use the event as an opportunity to make sure
> you have working failover plans.

This. If you shout down anyone who gets something wrong (and then fixes it), 
then you end up only with people who either :
a) Have such a thick skin that they really don't care at all what people say to 
them or think of them.
b) Don't make such mistakes because they don't ever take any risk or try and go 
beyond whatever is already scripted for them - ie they don't really do anything 
all that useful.
Neither personality is what the project needs.

Look around and there are some seriously impressive buildings/structures - 
cathedrals, bridges, and so on. None of these were built without making 
mistakes. Lots of them fell down - the people building them learned from their 
mistakes, added to the pool of knowledge, and so built ever grander structures. 
So lets all* be part of a team building a construction to be proud of, rather 
than being one of a group with pick axes digging away under the foundations.

* Sadly I don't think I can include myself in that as I don't have the 
knowledge and skills to contribute - I can install a system and configure 
packages, but my programming these days is limited to a bit of Bash. I am 
deeply in awe of those of you who can write code, build packages, etc, etc.


> Populism?  Egos?  Personalisation?  Sure.  Those happen, and are part of
> the carnival, because there are human beings involved

This.
Being a group of diverse people with different views, traits, skills, etc is 
what makes life interesting. Yes, people will upset each other from time to 
time - but that too is part of making life interesting.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Way forward

[Simon Hobson]

KatolaZ  wrote:

> I joined this project much before it was called Devuan, and I have
> always considered it a battle worth to be fought, day after day. I
> promised myself that I would have continued contributing to Devuan
> until the day we would have started talking corporate bullshit, or
> stopped trusting each other, or given up on having fun.
> 
> In the last ten days all those threee things have materialised, to
> different degrees. Hence, I have decided to withdraw from Devuan and
> will now take an indefinite leave from the project.

I would ask you to reconsider.

Wherever you go you will always find trolls and idiots who will spout off about 
anything that they don't like - especially if they haven't contributed. I've 
stayed out of the "discussion" because it was mostly pointless - and in a good 
part a rant from one idiot. I thought it was a pretty good April 1st, but I'm 
inclined to agree with those who think it was perhaps misjudged. But only on 
the "mild slap on the wrist, don't do it again" level of misjudged.

So, don't see all the hot air and think that it in any way reflects the 
majority view. I think a large majority (a silent one) think it's all 
overblown, time to forget about it, and just get on.

You still have my confidence - and thanks for all the work you, and everyone 
else, are doing.
So take a break if you feel you need it, but don't for one minute think that 
you're not welcome back as soon as you feel ready for it.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] What you saw on devuan.org yesterday was an April's fools joke

[Simon Hobson]

chillfan wrote:

> Katolaz is working very hard to ensure we have releases, but I didn't realise 
> he was doing all this even.

I didn't either.
So another +1 for Katolaz and all the work he's doing. And everyone else of 
course, but I think it's a bit unfair for people to be calling for heads on 
spikes (or one head on a spike) over a fairly good joke.

I can understand why some people get a bit upset, but really guys, lighten up. 
If there's no room for a bit of fun now and again then life gets a bit dull - 
like the corporate world of grey suites and endlist lists of things you aren't 
allowed to say or do.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] April's fools mess

[Simon Hobson]

Rick Moen  wrote:
> 
> Quoting etech3 (ete...@e-tech-systems.com):
> 
>> My advice to you is like the Marines motto: Lead, follow or get the
>> hell out of the way.
> 
> 
> 
> That might be the motto of _some_ group of marines, but FWIW actual
> service mottos are:

I suspect that he wasn't meaning official mottos, but a generic unofficial 
motto that's probably attributed to most armed services. And very applicable to 
civvy life as well.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Systemd as tragedy

[Simon Hobson]

Alessandro Selli  wrote:

>> Hard to believe I listened to the same talk Corbet
>> is describing. What I heard was a propaganda piece,
>> finding reasons to sell the systemd approach
>> to BSD conference attendees.
> 
>   Not really.  He points out there were good reasons to want a new init,
> that systemd was a try at innovating something that was old, and that
> this is a different matter compared to *how* that change was implemented.

Beat me to it. I listened and he did make many good points which you've pointed 
out much more elegantly than I would have managed. While picking out bits by 
time, I liked his dig at the state of Debian management at around 16 minutes in 
when he mentions "that vote" :-)

> "systemd makes heavy use of dbus. I'm not a big fan of dbus but i am a
> big fan of messages. [...] One of the things that I told the BSD people
> was basically we should write our own message transport. My version, if
> I were to write one, would be kernel resident rather than user space and
> would allow a lot more of security and authentication and access control
> elements on the actual bus endpoints".

Exactly. Whatever the merits (or otherwise) of dbus as an implementation of a 
messaging system, the function it's trying to implement is a good idea. Ditto 
udev. And to be honest, a significant chunk of systemd as well - the ideas are 
good, the implementation and the way it's been managed,  "no so good".

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Systemd as tragedy

[Simon Hobson]

Massimo Coppola  wrote:

> But I guess there's no need either to list all technical systemd issues here, 
> or accept the unsound logic that unkind developers are the only reason of 
> systemd criticism.

With all the hot air, I suspect that many people have lost sight of the 
distinction between an implementation of an idea (udev, dbus,systemd) and the 
idea itself (a better way of managing a system).

It's clear that systemd isn't the right implementation. And it's clear that 
Poettering isn't the right person to be doing it.
But I'd suggest that many of us "systemd - just say no" folks aren't 
fundamentally opposed to improvements where the improvement is actually better 
and not a bug ridden furball'

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Is NetworkManager supposed to work?

[Simon Hobson]

Simon Walter  wrote:

> Yes, wireless LAN works from all my other computers. The Internet is
> accessible from them. I have a router that does the PPPOE and DHCP and
> DNS and NTP and a bunch of other things (dd-wrt).
> 
> I can connect to the wireless LAN via NetworkManager. I am asked for a
> password. The connection is made. I can ping any ip address including
> 8.8.8.8.

So that sounds very much like NetworkManager is working - you have a working 
network connection !

> The /etc/resolv.conf contains "# Generated by Connection
> Manager\nnameserver 127.0.0.1\nnameserver ::1" which does have
> dnsmasq-base listening on port 53. I checked it (nmap 127.0.0.1 -p 53)
> and it was open.
> 
> That seems to make sense, but I have never seen a working NetworkManager
> setup. So I don't know what to expect.

Yes, you mentioned earlier that you were running dnsmasq - that means you are 
running a local DNS service. Have you configured that with the address(es) of 
at least one external DNS resolver. As I read the description on Wikipedia, 
dnsmasq is a forwarder not a resolver - that means that it can't do the 
recursive lookups a resolver does, just forward queries to an outside resolver 
and cache the responses.
If you haven't told dnsmasq where to get it's answers from, then it won't be 
working for you.



 wrote:

> I recognize the problem from a Ubuntu system i still have. Look for
> /etc/NetworkManager/NetworkManager.conf and comment out the line:
> dns=dnsmasq
> 
> After that logout or reboot and your DNS should work again.

I'm guessing that this disables using the local DNS service - if so then that's 
not fixing the problem (local DNS service not working), only fixing the symptom 
(by not trying to use the local service).

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Is NetworkManager supposed to work?

[Simon Hobson]

Simon Walter  wrote:

> Maybe there is some kind of conflict with another package. I have no DNS 
> resolution. I do not have the full dnsmasq package installed - just the 
> dnsmasq-base.

I think you need to take a step back and diagnose this logically. You need to 
start with the basics, and work up. "no DNS resolution" could range from "no 
physical network connection" at the lowest level up to "dns resolver is broken" 
at the top level ! If something low down doesn't work, then you need to stop 
and fix that before going further.

First, describe your setup : Is it wired or wireless, do you have a router 
that's connected to the internet and doing NAT etc, or are you connecting 
directly, or ... ?

Is using Wireless, are you getting a connection to the network ? If wired, is 
the link up ? (IIRC ip link show)

Do you get an IP address ? (ip addr show)

Do you have routing ? (ip route show - should see a default route via the 
router address)

Can packets get out at all ? (traceroute 8.8.8.8 - does it reach 8.8.8.8 or 
stop short)

Is a resolver configured ? (cat /etc/resolv.conf)

Does it work ? (dig google.com)
Does resolution work with an outside resolveer ? (dig @ 8.8.8.8 google.com)
May need to install the dig (domain internet groper) package.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Admins can you fix/set the header overrides?

[Simon Hobson]

Rick Moen  wrote:

> Back in the day, I gave out /etc/aliases entries to friends that
> leveraged the 'mafia' theme of my linuxmafia.com domain,

In our case it was simple alias entries ina  database queried by Postfix - but 
same effect and same problem.

> SRS (sender rewriting scheme) was SPF creator Meng Wong's kludge for
> salvaging /etc/alias and ~/.forward (when used cross-domain) from
> unintended collateral SPF damage.

Perhaps I'm missing something, but doesn't SRS provide a gaping wide chasm for 
spammers to pile through ? It always seemed to me a bit like server C getting a 
header that's been re-written in scuh a manner by server B that server C is 
expected to accept it as though server B is pinkie swearing that the forwarded 
mail is genuine and did come from server A. Or more precisely, server B 
effectively saying "this message from some other domain, well pretend it's 
coming from my domain"- so all a spammer has to do is forge (in a correct 
manner) the re-written from address and the spam bypasses SPF.
I guess that's why DKIM etc came along.

> Wong provided a Perl wrapper script to rewrite the SMTP envelope on the 
> outbound copy, emulating what MLMs do.

it was a few years ago now, so details are "a bit fuzzy" to say the least. In 
our case using Postfix, it needed some plugin to do it - and I think this 
plugin re-wrote all addresses regardless of where the email was headed. Due to 
the way the two services were done, the greylisting (part of policyd, aka 
Cluebringer) was done on the re-written address, and since this (IIRC) changed 
each day then few emails ever got the "seen this triplet before, straight 
through" treatment and so nearly all mail was delayed. Funny how users get to 
expect "instant" email even though there's never ever been any guarantee of 
instant delivery :-/

But at least my service did something that apparently the likes of Google and 
Microsoft couldn't manage - I did not have to silently delete mail that failed 
spam or embedded nasties checks. I rejected the messages so that any properly 
configured server would notify the sender that the message wasn't delivered. I 
was always proud of that bit.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Admins can you fix/set the header overrides?

[Simon Hobson]

Rick Moen  wrote:

> Simon, I appreciate your pitching in to attempt to answer this question.
> A few necessary corrections, though:

Correction noted. However, in my defence my issues (which I no longer have to 
deal with) were with mail forwarding in servers rather than mailing lists (IIRC 
our mailing list hosting had dwindled to just a couple of announce lists before 
the problem raised it's head) - so a different set of related issues which was 
primarily SPF at the time. I did get as far as having a look at SRS - but 
unfortunately the plugin for Postfix was incompatible with the greylisting I 
used due to the order of operations which prevented whitelisting of "known" 
greylisting triplets. Customised solutions were beyond my skill set - not to 
mention, the issues of leaving a maintenance time-bomb for any admin taking 
over*.

* When I left, a host developed a hardware issue. There was enough spare 
capacity to simply move the VM to another host - a few hours to copy the mail 
folders. Instead the know it all in charge took nearly a week to get something 
working because the concepts were beyond him. It was hard to laugh out load as 
I knew what it would be doing to the customers - many of whom I knew personally 
through having provided support over the years.


Rick Moen  wrote:

> Why messages fail DMARC is convoluted, and I'd frankly rather spend my
> time on other things.  If you are wanting to spend a lot more time on
> this, here's a fine place to start:
> https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail

Thanks for that, an interesting site.



Steve Litt  wrote:

> I'd suggest we ban email from gmail, yahoo, protonmail, and the rest
> that demand strict adherence to DMARC.

Nice thought, but do you really think that the likes of Google give a sh*t 
about some little mailing list somewhere, and which should be using Google's 
services anyway - how dare they use their own solution !
The reality is that the "big boys" have implemented these breakages - they knew 
beforehand that they would break almost all forms of forwarding, but their 
solution to that "problem" was simply to declare any form of mail forwarding as 
"improper" and therefore breaking it wasn't their fault. I can't help thinking 
that their marketing people saw an opportunity to make life harder for small 
scale competitors.

From the users' PoV, if a random mailing list or forwarding server doesn't work 
with such broken domains then clearly it has to be the little mailing list or 
forwarding server that's broken. For many years at a previous job we ran a mail 
server for customers - going back to before everyone and his dog were offering 
such services. We always recommended customers to create a second account in 
their mail software to (at a minimum) collect their mail - but many would 
simply refuse to countenance the complication - and instead we had to forward 
"i...@customersdomain.co.uk" to "someobscureaddress24673...@isp.com".
This worked just fine for many years - until that is, the big boys went out and 
broke it.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Admins can you fix/set the header overrides?

[Simon Hobson]

Michael  wrote:

>> Argh.  Sending to the list this time.
>> 
>> Please don't set "Reply-to" on list emails.
>> 
>> Antony.
> 
> I’m pretty sure the individuals aren’t doing it explicitly.  This list just 
> doesn’t seem to create, or override really, the headers quite right.  Some 
> messages here I hit reply (like this one) and the proper “To: 
> dng@lists.dyne.org” shows up, on others someone’s name is populated in the 
> To: box.  Other lists, you hit reply and To: is always populated correctly.
> 
> golinux?, other admins?, is there a config option somewhere in the backend 
> to ‘fix’ this?

Unfortunately I think it's one of those things where you have to break some 
stuff to work around the deliberate breakage implemented with malice 
aforethought by many large email providers.

The problem is SPF, DMARC, and friends. These basically provide information 
about where emails may come from - eg gmail may only come from Google's 
servers. This is a problem for any system that forwards email - such as mailing 
lists and mail servers setup to forward email for (say) 
i...@nicetownplumbers.co.uk to ntplumb2458...@someispmail.com.

So, someone using gmail sends a message to dng@lists.dyne.org which is 
delivered and then forwarded to all the list users. Some of those users will be 
using mail services that check SPF etc - and oh dear, there's an email which 
purports to come from gmail but it's actually being sent from a dyne.org 
server. So it gets discarded as obviously spam.

What they've down with the list (and I've seen it with other lists too) is: if 
the mail matches some criteria, then the originator's address is replaced with 
the list address and a reply to header is added. Thus for those users on a 
broken mail system (such as gmail, or hotmail, or ... they still get the list 
emails instead of not seeing mails from some proportion of list users.
The downside is what you see.

Not sure what the criteria are - whether it's based on there being certain 
headers in the email, whether the sender domain has SPF records etc, or what.

One answer is to always use reply to all and then move/remove addresses so you 
just have a single destination of the list address. I do ths all the time out 
of habit - partly because my mailer does somethings slightly differently with 
reply all, partly because I'm on a few lists and they all seem to do things 
differently (some have always left the senders address, some have always 
replaced it, some have always used a reply to, ...
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Drive-by critique

[Simon Hobson]

Rick Moen  wrote:

>> In part, Linux adoption is held back by its perceived difficulty
> 
> Just a brief comment about this in passing, as this is an antique debate 
> point ages ago stomped into the ground on comp.os.*.advocacy and other 
> places: An operating system one must install (not preloaded) will always be 
> perceived as 'difficult' compared to one already furnished as a point'n'drool 
> preload.

You know that, I know that, ...
And for years I've been installing OSs of various types : Apple DOS, MS/PC Dos, 
Windows from when it wasn't much more than a few windows on top of DOS, Mac OS, 
Mac OS X, Xenix, OpenServer, OS/2, and various flavours of Linux. I've even 
done a bit of embedded system work - mine was the human inteface part, but I 
also worked on the disk controller module (including determining by experiments 
what interleave factor worked best on the floppies) and test modules (it was an 
automated cable testing setup).
So yes, *I* know that Linux generally isn't any harder than others (drivers for 
OpenServer were a particular headache IIRC, not to mention RAID controllers for 
Windows) - but it still has this (invalid) perception based on reading about 
having to download drivers etc. I have to think hard for occasions when I've 
had to download drivers for Linux - the only ones I can think of were the 
closed ones for an nVidia card, and the binary firmware blobs for my TV tuner 
cards.
The last installs I had to do were Windows 10 at work, and TBH they were much 
more of a PITA given how MS seem to have gone out of their way to make things 
difficult for someone who doesn't want to be borged by their attempt to mimic 
Google's and FaecesBook's ability to grab and monetise user information. I'd 
keep a special place in hell for the people responsible for that abomination.

> ... just pointing out that the entire discussion is saturated with balderdash.

Agreed.

>> If there were lots more Linux users, and lots less Windows users, then 
>> that situation would change.
> 
> My Kansas-born mother would have said, 'If the hoptoad had wings, it wouldn't 
> bump its bottom on the prairie.'

I know a few more sayings along those lines - some of them not suitable for 
polite conversation ;-)

> In other words, if you start with an implausible premise, you can reach just 
> about any conclusion you want.  In this case, the credibility challeged 
> premise is 'lots less Windows users', as that is obviously not likely for the 
> foreseeable future.  The PeeCee OEM preload monopoly is a thing, and even the 
> rise of smartphones and tablets hasn't made a dent in it.

The point being made is WHY things are as they are - which is that there's no 
business driver for hardware manufacturers to support Linux. I agree that we 
are where we are and that's not going to change quickly - if it did then that 
part of the catch-22 situation would be broken, but I won't be holding my 
breath for it !


But as you point out, any analysis of why doesn't really alter the fact that 
for most people computing == Windows (or for some, Mac OS X which is IMO less 
bad) and internet == Google + FaecesBook. Anything else is strange, different, 
and therefore "difficult". That's going to take some changing.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Drive-by critique

[Simon Hobson]

Rick Moen  wrote:

>> I agree. The more GNU/Linux blows off prospective users by making them
>> jump through hoops, the more Linux becomes a niche. The nichier Linux
>> becomes, the more the hardware manufacturers ignore it. Let GNU/Linux
>> get up to 25% on the desktop, and the manufacturers will provide good
>> drivers for everything they make.

> I can hazard a guess about why I keep hearing this 'desktop mindshare' 
> argument with no recognition of the vital differences that make it
> pretty much inapplicable:  It's a leftover, reflexive proprietary-OS way of
> thinking (or, to be blunt, of not thinking).  Free your mind, Steve.  ;-> 

I think you are both right (in part) and both wrong (in part) !

Rick, you more or less support Steve's argument in your rebuttal. For Windows, 
device manufacturers provide the drivers because without that they don't get to 
play in the big pond - and without playing in the big pond, they have no 
business. Because Linux is a little pond (or even puddle, in their eyes), they 
don't have to care.
So we have, to an extent, a chicken and egg situation. In part, Linux adoption 
is held back by it's perceived difficulty - such as having to go and find 
drivers for your hardware. In part, the reason for that is that device 
manufacturers don't provide drivers/support development of them. In part, the 
reason for not providing/supporting drivers is that they don't see/care about 
the "little pond" that is Linux users and so don't see a business driver to do 
it.

If there were lots more Linux users, and lots less Windows users, then that 
situation would change. There'd be a louder voice for them to hear of "if you 
want us to buy your devices, you need to provide the drivers (or support their 
development)" - and so there'd be a business case for doing just that. There's 
a difference between the business case spending money to add (say) 5% to your 
potential market vs spending that money to add (say) 30% to the potential 
market.

But even that is, in part, irrelevant. When you have things like a dominant 
player (Microsoft) actively forcing (video) device manufacturers to make their 
products more fragile and harder to reverse engineer. As I read the situation, 
if a video card manufacturer wants to play in the Microsoft world of "trusted 
video paths" then they have to build something that is fundamentally at odds 
with having good open source drivers available - they have to purposefully make 
things more fragile by detecting attempts to "look into" the internals and 
"breaking" if anything does something "not approved" such as trying different 
things to see what they do (as in part of reverse engineering a driver).

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Request for comments - training room

[Simon Hobson]

g4sra  wrote:

>> How is the Linux server going to authenticate users, via /etc/passwd or
>> other ?
>> 
>> A lot depends on this, also the number of users will have a factor as
>> well.

> Which network authentication method would you suggest ?

I think what Roland was getting at here is the number of users and how they are 
dealt with makes a huge difference.

At one extreme, you have 28 seats, each one of them has a user such as "user1", 
and you can simply use /etc/passwd & /etc/shadow to manage that single user one 
each seat. You could probably build one software image and simply image all 28 
machines with that one image.

At the other extreme, every person has their own login and can use any seat at 
any time (and there are hundreds or even thousands of them) so that 
progress/results can be logged for each person. In this case, you will really 
need a centralised user management such as Roland described using Samba & AD.
You could still image each machine from one common image - but you'll need to 
do some post-imaging setup to give each machine a unique set of identifiers etc 
for the AD to work properly.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Dng now alters (some) posts to compensate for DMARC antiforgery

[Simon Hobson]

Rick Moen  wrote:

> I heartily second your thanks to the mailing list administration team.

+1
Having run mail & list servers I've seen the problems caused by the big outfits 
who are happy to just declare "oh that's no longer valid - we don't care about 
breaking it". And I reckon I managed a better uptime than Microsoft with their 
Office 359 service ;-)
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Request for comments - training room

[Simon Hobson]

Dr. Nikolaus Klepp  wrote:

> Hm ... on devuan mailinglist asking for trainingroom setup for 600 active 
> user? I don't think server nor clients are M$-based, but I could be wrong 
> here :-)

Windoze isn't the only GUI desktop around ;-)

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Request for comments - training room

[Simon Hobson]

Bruce Ferrell  wrote:

> I've found that AD is VERY sensitive to time differences, even in a pure 
> windows environment.  How Windows admins tolerate it I have yet to figure out.

AIUI the DEFAULT in a Windoze network is that all the Domain Controllers are 
also time servers (not NTP, MS's own creation) and the master DC takes on the 
role of root time server. Domain joined PCs will sync their time from the DCs. 
That way, the whole domain *should* normally stay in sync - ie it will be 
internally consistent but not necessarily correct wrt real wallclock time. For 
the times to stay correct, the master DC needs to be configured to use an 
external time reference.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Request for comments - training room

[Simon Hobson]

g4sra  wrote:

> To clarify some points raised.
> 
> 1) Approx 200 trainees each year, the full course is three years long (but 
> class size will be 30 maximum at any one session). By year 3... 600 Users. 
> After year 3 the trainees details may be purged and resources reclaimed so 
> the server will never have to support more than 600 accounts.
> 
> 2) The trainees progress is stored in a .subdirectory of their home directory 
> by the (annoyingly) proprietary closed source training software.
> 
> 3) The trainees cannot be guaranteed to be sat in the same seat at every 
> training session. In fact, must move to one of the few workstations with a 
> joystick\graphical tablet for specific lessons.

OK those 3 pretty well mandate centralised user management - Samba AD, NIS, 
whatever. Items 2&3 pretty well mandates using a central file server mounted at 
each user workstation for the users' files.
For file sharing, there are pros and cons for different methods. NFS has the 
advantage of allowing a single mount that works for all users - the 
security/permissions management is done by the client system which in this case 
is a machine you manage and can trust (as long as it's been reasonably well 
secured against "inquisitive" users. Samba needs a mount/user and 
security/permissions is handled by the server. A bit of "6 of one, half a dozen 
of the other".

> 4) A downed workstation must be easily replaced without loss of trainees work.

Home directory & files in server, plus automatic rebuild for workstations - box 
ticked.


Would have saved a bit of speculation and discussion had these details been 
provided earlier :-/

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Request for comments - training room

[Simon Hobson]

Rowland Penny  wrote:

> If you could set up such a scenario, then yes, your way could be used,
> but there was a mention of a server. If you have a server, you usually
> get files saved and read, so how do you differentiate between user
> 'fred' from computer18 and 'fred' from computer23 ?

I did include the proviso that the training system handles recording progress 
etc. As I read it, each station loads the training system from the server - 
which could be just serving read-ony files, or it could be serving read-only 
files plus a database, or it could be serving the files plus running a database 
and a central management program that co-ordinates the training.

If there's a need to store user-specific files, then you are correct that 
having just the one user across all the seats won't work.

But I don't think we've been given enough detail to say where on the spectrum 
this system sits.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Request for comments - training room

[Simon Hobson]

Rowland Penny  wrote:

>> Indeed, but this scenario is for a fixed setup where the users (28 of
>> them) are setup once and then there is no further user maintenance
>> going forward. In such a scenario, there's little point in going for
>> the complexity of setting up AD - as you say, a one-off setup of the
>> users in Samba. The clients could potentially be configured to
>> auto-login to the desktop (or training system) on boot so the users
>> don't even need to know about users. Easy for users, no security.
> 
> Been there, done that, but with that many computers it becomes a
> struggle, the users want to use different computers and cannot because
> they are not set up on that computer, believe me, if you are setting
> something up of this size, a domain is the way to go.

Sorry, I think you missed the point of the scenario I was talking about. This 
one is where the users don't have their own login - they all use just the same 
login, so can sit down at any machine and use the single login that's 
configured on the machine, and there's no need for any user management on each 
machine other than setting up the one user login. That might be appropriate if 
the training system handles user management etc.

Otherwise, I agree with you.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Request for comments - training room

[Simon Hobson]

Rowland Penny  wrote:

>> I think what Roland was getting at here is the number of users and
>> how they are dealt with makes a huge difference.
>> 
>> At one extreme, you have 28 seats, each one of them has a user such
>> as "user1", and you can simply use /etc/passwd & /etc/shadow to
>> manage that single user one each seat. You could probably build one
>> software image and simply image all 28 machines with that one image.
> 
> This would entail running Samba as a workgroup and, once you get past
> about 10 machines, it get unwieldy, you have to create the exact same
> users on every machine you want them to connect to and keep their
> passwords in sync. This can rapidly become a nightmare, this applies
> if you decide to go with NFS instead.

Indeed, but this scenario is for a fixed setup where the users (28 of them) are 
setup once and then there is no further user maintenance going forward. In such 
a scenario, there's little point in going for the complexity of setting up AD - 
as you say, a one-off setup of the users in Samba. The clients could 
potentially be configured to auto-login to the desktop (or training system) on 
boot so the users don't even need to know about users.
Easy for users, no security.

>> At the other extreme, every person has their own login and can use
>> any seat at any time (and there are hundreds or even thousands of
>> them) so that progress/results can be logged for each person. In this
>> case, you will really need a centralised user management such as
>> Roland described using Samba & AD. You could still image each machine
>> from one common image - but you'll need to do some post-imaging setup
>> to give each machine a unique set of identifiers etc for the AD to
>> work properly.
> 
> If you run Samba as an AD DC and join the clients to this, you only
> have to create the users & groups once and the password is only stored
> in one place, the DC.

Exactly - for many users, and especially if the users are dynamic, then it's 
the only sane way to do it.

And it also means that each user has their own personal login & home directory 
so (if it isn't stored in a database that's part of the training system) there 
is somewhere for the system to store each users progress etc.

Which leads to another question ... Does the training system itself have a user 
directory etc ? This also has an impact on the solution chosen.

If the training system has a logon for each user and stores (eg) progress 
information in it's own database, then it makes little sense to also configure 
each user separately to the OS (eg using Samba & AD). Just setup the machines 
as above with a single user and manage users via the training system.
On the other hand, if the database (the schema, not just the DB engine) is 
"open" enough then it may be possible to use that as an authentication source - 
giving each user their own OS level login which is the same as the traingin 
system login, but using just the one database.

Many possibilities - the "best" for any setup depends on answers to these sorts 
of questions.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Request for comments - training room

[Simon Hobson]

g4sra  wrote:

>> How is the Linux server going to authenticate users, via /etc/passwd or
>> other ?
>> 
>> A lot depends on this, also the number of users will have a factor as
>> well.

> Which network authentication method would you suggest ?

I think what Roland was getting at here is the number of users and how they are 
dealt with makes a huge difference.

At one extreme, you have 28 seats, each one of them has a user such as "user1", 
and you can simply use /etc/passwd & /etc/shadow to manage that single user one 
each seat. You could probably build one software image and simply image all 28 
machines with that one image.

At the other extreme, every person has their own login and can use any seat at 
any time (and there are hundreds or even thousands of them) so that 
progress/results can be logged for each person. In this case, you will really 
need a centralised user management such as Roland described using Samba & AD.
You could still image each machine from one common image - but you'll need to 
do some post-imaging setup to give each machine a unique set of identifiers etc 
for the AD to work properly.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Request for comments - training room

[Simon Hobson]

Steve Litt  wrote:

>> 
>> Do not run cables across the floor (taped down or otherwise), this
>> would be a trip hazard.
> 
> What other alternative is there for a temporary installation?

Hung from the ceiling ? How practical that is depends on ceiling height, 
construction (suspended ceilings give easy access to the frame to put loops 
round), etc.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Participate to the first Devuan Conference in Amsterdam!

[Simon Hobson]

Adam Borowski  wrote:

>> Walking around Glasgow, you might find
>> the brogue bewildering, but in Amsterdam?  Never.
> 
> There are worse cases.  There's a place called "London", where a sign says
> "Sloane Square" yet the station announcement (by a person paid to have clear
> diction) says "Ten Ske".
> 
> So people in, say, Stockholm, bother to learn English, people in London
> don't.

Ha, yes that is true !

I think it was Jasper Carrot (a brit comedian from Birmingham 
https://en.wikipedia.org/wiki/Jasper_Carrott) who did a gag some years ago 
about how foreigners go to great lengths to learn English - then they come here 
and find that we don't speak it. A significant element of his comedy was maming 
fun of the Birmingham accept (or "Brummy").

And if we find ourselves talking to a call centre in Glasgow - well that's 
worse than the ones in India :D

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] /usr to merge or not to merge... that is the question??

[Simon Hobson]

goli...@dyne.org wrote:

> So . . . if the choice to avoid the merge is only available with 
> debian-installer what does that mean for the live isos?  Will they be 
> configured with or without the merge as default?

Does it make any difference at all on a live ISO ? If it's setup merged, then 
anything referencing /bin (etc) will follow the symlink and access /usr/bin 
(etc).
However, as the default for Devuan seems likely to be unmerged, then it would 
make sense for the live ISOs to be the same. Scripts etc will have to be 
written to deal with the unmerged (split) layout so nothing should break that 
way - unless the script is written by someone assuming that nothing in the 
world runs unsplit any more. Any such scripts will need fixing to run on 
installed systems anyway, so would then run on a live ISO with split 
directories.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] /usr to merge or not to merge... that is the question??

[Simon Hobson]

Alessandro Selli  wrote:

> If Devuan is going to have a brilliant future it is going to disenfranchise 
> itself from Debian.  Being forever a Debian without systemd will keep it in 
> the backseat, vulnerable to all the odd decisions and arguable development 
> directions that Devuan/FD are going to take.

In the long term, Devuan is likely to slowly diverge from Debian - and 
hopefully will gather support from Debian devs/package maintainers fed up with 
the Debian shenanigans. it's even possible to foresee a time when Devuan 
overtakes Debian and Debian ends up as a derivative of Devuan - but a long time 
off I think.
In the meantime, there simply are not enough Devuan devs to simply dump Debian 
as an upstream. At the moment, most packages available in Devuan are unmodified 
Debian packages - there simply is no justification for re-inventing loads of 
stuff that doesn't need re-inventing, it would be a waste of effort. In the 
meantime, the devs the Devuan project does have can tackle those packages that 
need work - mostly de-systemdising broken packages and making substitutes for 
some bits.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] reliability (Was: /usr to merge or not to merge... that is the question??)

[Simon Hobson]

Daniel Taylor  wrote:

> It's scary how unreliable our systems used to be compared to now.

Were they ? Or did they just have different fragilities ?
Example:
There's the discussion here about having essential tools available without 
having all filesystems mounted. Go back to the times under discussion and we 
had relatively primitive filesystems without journalling - so an uncontrolled 
shutdown (crash, power loss, ...) was highly likely to cause some filesystem 
damage and need at least a fsck to fix it. Now we routinely have journalling 
filesystems and I note that in most cases there's a quick "replay the log, were 
Ok to go" step during the next boot after a crash.
So there's one aspect where we now have more reliable systems.

But, our systems are so much more complicated now. Once over we had "static" 
hardware, and when changing it you had to (or the device driver installation 
had to) run some admin program that would update the static device nodes in 
/dev. As long as the hardware didn't change, your /dev would reliably have the 
right nodes in it - and you could manually change the device files if needed 
and the changes would be persistent. Now we have dynamic /dev nodes - which 
while very convenient is also subject to a a certain amount of "plug and pray", 
and fixing issues can mean delving into non-trivial config files to get a 
persistent change.
So one aspect where systems are less reliable.

Overall I suspect that there isn't much of a net gain or loss - just a 
different set of problems.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] initramfs?

[Simon Hobson]

Hendrik Boom  wrote:

> (1) Is initramfs so weird that only one or two people in the world can make 
> one?

**AT THE MOMENT** no it isn't. AIUI (and I stand to be corrected) it's simply a 
CPIO archive that's been (optionally) compressed. So it can be uncompressed, 
extracted, modified, and rebuilt using standard tools.
Also ** at the moment** I can't see that changing since the process that needs 
to extract that archive at boot time isn't under Poettering's control.

As for the future - who knows.

Also, echoing another comment, I can't remember ever having to fiddle with the 
contents of one as a means of fixing a problem.


> (2) What is initramfs good for?  Linux used to work just fine without it.

Yes, I remember the days of having to have either a) a huge kernel with 
everything including the kitchen sink linked in, or b) having to relink the 
kernel when the hardware changes. And back when I had SCO Openserver under my 
remit, making boot (hence placing a limit on kernel size) and root floppies for 
emergency booting - oh the fun of working out what I could leave off the root 
floppy to make space for CPIO ...

I can certainly see the use of initramfs : It allows the use of modular kernels 
(so non of this "you've changed something, lets relink" malarky), and gets 
round the catch 22 of needing to mount a filesystem before you can load the 
modules you need to mount the filesystems.
If you'd prefer not to use it, then you can manually link the modules you need 
to be able to mount the filesystems into your custom kernel and do it the old 
way.

Is it easier building initramfs images than statically linking  kernel ? Dunno, 
but that's the way we've gone - and I'd say (see above) that an initramfs is 
less opaque than a statically linked kernel.


As to the original question ...
I have no strong feelings either way, but as has already been mentioned, once 
Debian goes merged, then it's inevitable that more and more packages will 
assume a merged system. The work required to maintain a derived distro keeping 
separate /usr/bin and /bin etc will keep increasing. Given the limited dev 
resource available to Devuan, one has to question whether it would be a good 
investment to maintain the split.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Online DNS & Bind Refeences.

[Simon Hobson]

terryc  wrote:

> The problem I'm hitting is the format of woa.com.au/192.168.0.0 zone
> files and despite carefully deriving ones from examples in the Debian
> wiki I'm getting conflicting error listing. Frustrating.

What sort of problems are you getting ? Some of us here have a bit of 
experience with BIND.

Or there's the BIND-users mailing list where I've found the regulars helpful in 
the past.
https://lists.isc.org/mailman/listinfo/bind-users

And don't forget that there's a manual for BIND, the BIND Advanced Reference 
Manual where everything is documented.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Command to permanently prevent sysvinit from starting daemon

[Simon Hobson]

Arnt Karlsen  wrote:

> ..well, that's still 256 possible runlevel names. ;o)

TBH, I don't think there's all that much scope for **usefully** using lots of 
runlevels.

To start with, (near enough) every package comes with a control script for rc 
to use - and which contains comments to signal to the management scripts what 
runlevels the daemon in intended to run in. So you'd have to edit all of those 
so that update-rc can do it's job easily. And of course, once you do that then 
you get into all the problems that come with editing package supplied files- 
having to choose between your own or the (possibly updated) package supplied 
one, and re-applying changes if you choose to use the updated package supplied 
file.

And then there is the issue that if you want different combinations of daemons 
running, then you need to list all those that need to run in each combination. 
Unless you only need a small number of combinations (in which case the spare 
ones of 3,4,5 are likely to suffice) then it's likely to turn into quite a PITA.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Stop the madness!

[Simon Hobson]

Steve Litt  wrote:

> What I said was that if you like sysvinit, use it, but for gosh sakes
> don't take the time and energy to modify it or update it or give it
> systemd features.

+1
Old does not equal broken. Perhaps the reason sysvinit hasn't seen much 
maintenance for a while is that it just hasn't needed it - if it ain't broke, 
don't fix it !

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Stop the madness!

[Simon Hobson]

Steve Litt  wrote:

> Stop the madness!

+1, many times over !

> And, of course, pushbuttons and dials by their very nature are limiting

Yes, yes.

> Some Devuaners will say "but wait, bad as that is, it's still better
> than modern init scripts."

It is true that **SOME** init scripts have become rather bloated. But most are 
quite simple - and I really don't see the problem with them. When a major 
complaint is seeing the "complexity" of a case statement to decide what to do 
for each possible operation (meaning you can have as many arbitrary ones, not 
just stop, start, status), you have to wonder at the skills of those doing the 
complaining !

I really can't see why code that's there to be seen (and edited if needed) is 
somehow inferior to hiding the same code (and more) in some binary blob 
controlled by a load of buttons and dials - and all to achieve something less 
capable.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [devuan-dev] Debian Buster release to partially drop non-systemd support

[Simon Hobson]

Steve Litt  wrote:

> "Multi-seat" makes little sense now that when you add a user you can give him 
> or her a $400 computer with which he can share the server's data.

I would beg to disagree - at least for some workloads. I think "it depends" is 
often teh answer to the question of "is multi-seat of any use ?"

For your typical "office stuff" - WP, Email, etc - then I;d agree, a desktop PC 
with shared access to the file server is great.
But back a couple of jobs ...
We ran a Unix system (SCO OpenServer before SCO hit the self destruct button) 
with a large number of users. The primary tool used by most users was a single 
application which did all the sales, purchasing, stock control etc, etc. Mostly 
these were Wyse60 terminals - partly for historical reasons, the previous 
system was hard-coded for a Wyse 60. Running serial at 9600bps was quite 
adequate to give a good response time and almost all* the time this worked fine 
with anything up to 100 users on a Pentium with 16G RAM.
In terms of data, it would make zero sense to have remote processing sharing 
the data off the server - the sales order detail (line items on sales orders) 
DB file would exceed 1G without any trouble. Since most of the work is database 
transactions, there is no sane alternative to a central DB server doing all the 
DB stuff. So even if you go to PCs on every desktop, you are still down to the 
client being an "intelligent display".
As it happens, a later version of the program did have a native Windows client 
- which was basically a Window-ised version of the text interface. As it was, 
many users were migrating to Windows PCs using a terminal network over ethernet 
for the main system, and the usual sort of "office stuff" they got Windows for.

But back to the clients we used, there is absolutely nothing as simple to 
manage on the factory floor tan a "green screen" terminal. It's really hard for 
the hammer fingered users to mess them up - and if they do, then it's generally 
nothing more than swapping out the broken one for a good one with zero config 
needed. Once you go to something more complicated, then the management costs go 
up - regardless of what system you use, there is more work in either manually 
configuring systems or setting up an automated system to do it.

Oh yes, and did I mention that we ran across multiple sites ? For a while we 
ran about 10 users across a 19.2k leased line - that got upgraded to 64k when 
one of the serial muxes died and we upgraded to IP networking and terminal 
servers.


* I said "almost all" the time. Any of you familiar with SCO OpenServer 5 will 
know that it has a link time configured disk buffer size, with a maximum size 
of 640,000kbytes - and yes, the system failed to boot if set to 640,001 kbytes. 
And note what I said about one single db file getting to over 1G, some of you 
will be ahead of me and know what's coming. The reporting tool that came with 
the package had an "interesting" feature in that it would suddenly stop using 
indexes for joins - you'd be developing a report and all would run fine, then a 
minor change and performance drops faster than a lead balloon. Non-indexed 
joins with files well over 1G and only 640M of disk cache - yup the system 
slows to a crawl with 99 to 100% wio and a long disk queue. We;d know if 
someone ran this particular report during the working day when the phones rang 
to say the system was frozen - everyone got stuck waiting for disk i/o. That 
was with fast (for their day) wide SCSI drives, arrayed across busses for 
maximum performance.
In the end, it got to be run over the weekend and took 40 hours. At some point 
I re-wrote it in Informix SQL, taking care over use of indexes, and we could 
run it at any time without upsetting users and get the results in under 2 
minutes.

I was looking forward to us upgrading as a later version could run on Linux - 
and thus make use of more memory, would have been lovely to keep the DB in 
cache. It didn't happen while I was there, there was a bit of a business 
downturn and I was one of the ones that paid off.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng