Re: [GLLUG] Ubuntu versus Debian (was: Re: GLLUG still alive?)

2024-08-28 Thread Andy Smith via GLLUG
On Wed, Aug 28, 2024 at 05:52:25PM +0100, Vincenzo Barranco via GLLUG wrote:
> Why would anyone use ScamBuntu when you have Debian ?

Why would top-posting edgelords who dismiss the choices of literally
millions of actual Linux users be quite an ironic thing to see in a
thread about whether a Linux User Group is dead now ?

https://strugglers.net/~andy/imgs/stop_liking.jpg

-- 
GLLUG mailing list
GLLUG@mailman.lug.org.uk
https://mailman.lug.org.uk/mailman/listinfo/gllug


Re: [GLLUG] FReexian ELTS and Ubuntu Pro (Was Re: Ubuntu versus Debian)

2024-08-24 Thread Andy Smith via GLLUG
Hi,

On Sat, Aug 24, 2024 at 07:10:10PM +0100, Carles Pina i Estany via GLLUG wrote:
> > On Fri, Aug 23, 2024 at 09:57:55AM +, Tim Woodall via GLLUG wrote:
> > > On Wed, 14 Aug 2024, Alan Pope via GLLUG wrote:
> > > > They then make that paid work available for free to the Ubuntu 
> > > > community if
> > > > they enable Ubuntu Pro.
> 
> To me, what was described would be Freexian LTS (not ELTS).

They both (LTS and ELTS) are providing security backports for Debian
packages past the end of the stable release by having sponsors pay
consultants to make the packages. The produced packages are
available for free to everyone in the world. LTS updates go into the
Debian archive; ELTS updates are only in Freexian's archives but are
still publicly available.

The Freexian LTS sponsors pay a quarterly or yearly fee on one of
several different tiers. The lowest tier, basic, is €255+VAT per
year. The highest tier, platinum, is €24,480 per year. Paying more
puts more person-hours into the pool and increases the priority of
your package list. At bronze level (€1,020 per year) or above you
get access to a private mailing list to ask the LTS people for
advice, and even higher tiers get to talk directly to the Freexian
consultants. They try to support the whole Debian archive for the
main architectures in priority order until the hours run out, but do
exclude some things. The support lasts for 2 more years beyond the
end of Debian stable.

All of these details and more are at:

https://www.freexian.com/lts/debian/

Freexian ELTS is more limited. Instead of the whole archive it is
strictly packages that have been quoted for. It costs hugely more
than LTS sponsorship as discussed. This support lasts another 5
years.

The Freexian LTS consultants bill Freexian at €85/hour but it is
noted on https://www.freexian.com/lts/debian/details/ that this is
less than what Freexian charges sponsors, so each €255 paid covers
something less than 3 person-hours. I do not know if ELTS developers
are paid at the same rate.

> > > > They then make that paid work available for free to the Ubuntu 
> > > > community if
> > > > they enable Ubuntu Pro.
> 
> Above is similar to Freexian LTS ( https://www.freexian.com/lts/debian/ )

The topic of this sub thread is how it's NOT similar because you
have to pay for Ubuntu Pro if you want it for business use, and if
you want it free for personal use you have to sign up for an
account. Freexian's output is available for free without
registration. You (optionally) pay for the project to exist at all
and to secondarily have some minor influence on their priorities.

Also I suggest that Ubuntu Pro's support is probably more complete
over the more limited set of packages they cover (Ubuntu
main+universe is much smaller than Debian, but Freexian probably
don't manage to cover more packages than Ubuntu Pro do, and not for
as long). In short, you pay in some way for Ubuntu Pro and in
return get more certainty.

So I see more difference than commonality in these proposals.

Perhaps it could be possible to get figures for the total
person-hours paid for Freexian LTS and maybe compare it to what is
known of the number of full time engineers that Canonical is
employing for Ubuntu Pro.

Though even if Freexian stopped doing this I would still personally
prefer Debian at present.

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

-- 
GLLUG mailing list
GLLUG@mailman.lug.org.uk
https://mailman.lug.org.uk/mailman/listinfo/gllug


[GLLUG] FReexian ELTS and Ubuntu Pro (Was Re: Ubuntu versus Debian)

2024-08-23 Thread Andy Smith via GLLUG
Hi,

On Fri, Aug 23, 2024 at 09:57:55AM +, Tim Woodall via GLLUG wrote:
> On Wed, 14 Aug 2024, Alan Pope via GLLUG wrote:
> > They then make that paid work available for free to the Ubuntu community if
> > they enable Ubuntu Pro.
> 
> Isn't this the Freexian elts model for Debian?

I don't think it's really comparable as Freexian ELTS is an
expensive and almost bespoke consultancy service for a further 5
years after the end of Freexian's LTS.

You have to send them your list of important packages and they will
quote you how much to support them for a further 5 years, and the
cost goes up dramatically over time.

If you look at
https://www.freexian.com/lts/extended/docs/cost-estimation/ you'll
see an estimation there based on 150 packages of interest. The quote
starts at 7,770€ for the first year and ends at 24,570€ for the final
year.

I'm not an Ubuntu user but I don't think Ubuntu Pro is going to be
that costly for most of its users.

Of course, there's also the very different charging models: Freexian
is charging per package (so likely taking into account how much work
they think individual packages will be amortised across how many
sponsors are interested) whereas Canonical is trying to charge on a
per-host basis. Eventually Freexian will obviously work out cheaper,
but not for the small customer.

Ubuntu Pro is also promising security support on all of
Main+Universe for one price whereas the many thousands more packages
in Debian demand that Freexian ask for the list of important
packages and only quote for those.

Apart from the fact that they both end up with longer-term support
of packages, supported by people paying, I don't think they are
that similar.

The Freexian offerings (both LTS and ELTS) are appealing in the
sense that it is more of a community thing; orgs who really need
this support pay for it and then everyone can benefit. However,
unless you are willing to pay Freexian prices you don't get any
certainties.

I don't think Canonical are doing anything wrong by trying a
different approach and arguably it reaches more people. The
existence of Ubuntu Pro isn't what turned me off of Ubuntu.

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

-- 
GLLUG mailing list
GLLUG@mailman.lug.org.uk
https://mailman.lug.org.uk/mailman/listinfo/gllug


Re: [GLLUG] Using LLM for support answers - please don't (Was Re: British Gas DKIM failure?)

2024-01-28 Thread Andy Smith via GLLUG
Hello,

On Sun, Jan 28, 2024 at 02:37:45PM +, Jan van Bergen via GLLUG wrote:
> How Carles used it, with giving a reference stating that the lines in
> question came from a LLM, while still making sure that the info is correct
> to me is very much how you should use tools like this, and I had absolutely
> no issue with it.

My issues with it are pretty much the same as StackOverflow's issues
with it.

Any of us could have done the same, including Henrik themselves. Do
we want support venues that are just people pasting ChatGPT to each
other, web searches pulling back hits that are just more of that?

We have to spot that it's from an LLM and check the reference
ourselves. We don't know whether Carles did that for us. We can't
generally trust the LLM user to do that.

Carles could have asked the LLM the question, done the research
themselves to check that what the LLM came back with is correct, and
then written a response that they believe to be true and factual, in
which case that's fine. But we don't know that happened because it's
just a paste from ChatGPT.

> Maybe you're a language virtuoso and don't need tools to write,
> not everybody is like that.

Nice personal attack noted, but we aren't talking about writing prose.

> Let's try to be nice to eachother, especially when somebody is doing
> his/her/its best to help

I think my request was politely phrased and backed up with good
reasoning, whether you agree with the reasoning or not. I don't
think that pasting ChatGPT responses is someone doing their best to
help people.

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

-- 
GLLUG mailing list
GLLUG@mailman.lug.org.uk
https://mailman.lug.org.uk/mailman/listinfo/gllug


[GLLUG] Using LLM for support answers - please don't (Was Re: British Gas DKIM failure?)

2024-01-28 Thread Andy Smith via GLLUG
Hello,

On Sun, Jan 28, 2024 at 12:42:20AM +, Carles Pina i Estany via GLLUG wrote:
> (this is a copy-paste from a... ChatGPT conversation):

Please don't.

If this was a StackOverflow site, your response would not be
permitted because you used an LLM (ChatGPT).

I think that StackOverflow's reasoning for their policy is sound and
would apply here also:


https://meta.stackoverflow.com/questions/421831/temporary-policy-generative-ai-e-g-chatgpt-is-banned

In a nutshell, any of us, including Henrik, can easily use an LLM
yet what we can't easily do without domain knowledge is tell when an
LLM is *incorrect*.

When someone asks a question on a mailing list like this, I'd like
to think their question would be given as much respect as if it were
asked on a Stack site.

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

-- 
GLLUG mailing list
GLLUG@mailman.lug.org.uk
https://mailman.lug.org.uk/mailman/listinfo/gllug


Re: [GLLUG] British Gas DKIM failure?

2024-01-15 Thread Andy Smith via GLLUG
Hi,

On Sun, Jan 14, 2024 at 06:06:56PM +, Marco van Beek via GLLUG wrote:
> So looking at this, and Andy's email with what he sees, it looks like his
> British Gas emails are coming from a different place to yours. His are
> coming from SalesForce, and yours are coming from Mail Jet, so I don't think
> we can draw much from that.

I should maybe have gone a bit further back, as those last two
emails were both about the upcoming changes to the price cap, so
conceivably might have been sent from a different system than, say,
an account statement.

I shall have a look when I'm not camped out on a datacentre floor…

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

-- 
GLLUG mailing list
GLLUG@mailman.lug.org.uk
https://mailman.lug.org.uk/mailman/listinfo/gllug


Re: [GLLUG] British Gas DKIM failure?

2024-01-12 Thread Andy Smith via GLLUG
Hello,

On Fri, Jan 12, 2024 at 03:48:17PM +, Henrik Morsing via GLLUG wrote:
> The problem is, not receiving the email, how can I find out what
> the problem is? mxtoolbox says their setup is fine, but that
> surely can't check the signature inside one of their emails.

The last two emails I got from britishgas were as follows

KIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; s=50dkim1;
d=mail.energy.britishgas.co.uk;
h=From:To:Subject:Date:List-Help:MIME-Version:Reply-To:List-ID:
X-CSA-Complaints:Message-ID:Content-Type;
i=serv...@mail.energy.britishgas.co.uk;
bh=QMYT+RDkU4FYUyf7M4FXTSUBCO1hzJNcsLmSKfzziAs=;

b=hfEOZ/D56Cu8Rq3xGoqQ8gl0r3DkeHnoOD0a8VhimuW8NX111M4dZrW16lwjTzI6sMK/mimu8/fq

uilPS//eo9auRP63DzW6nMXls/0yFga1YTqRIB2Jra5qx82L23BOdIbltllAM9F2nQ9uw5ndg+7L

C2woxf/xLEqSeCWZoG6NM5vyG1/hTxvReikCLwMe5ZIvVc4+So2TTIj56+LL/NfvuWaQd6K02JLQ

53qIHHxmeODjdBbY9d0hwonw75Y13qxLZWM8Rt+LkscAp5+YXt7PleTSwmBO4BeRYO3mianhQQ9T
dXg1JbS0QZMV4mTCPN582dSVdIrM4WmVmtvm4g==
From: British Gas Energy 
Date: Wed, 22 Nov 2023 07:36:27 -0600
X-Spam-ASN: AS14340 161.71.0.0/17

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; s=50dkim1;
d=mail.energy.britishgas.co.uk;
h=From:To:Subject:Date:List-Help:MIME-Version:Reply-To:List-ID:
X-CSA-Complaints:Message-ID:Content-Type;
i=serv...@mail.energy.britishgas.co.uk;
bh=B+srJaEDKRO05DxBfcpT59B2n5VWQfXHWAmvNYAA4vo=;

b=Gxs6BnfoCDd45O/19TTBdE032a3Pzboox3XiSKEFzfp25HvWOpgwISOvNQB9yDtvM1Rh/Xna0K2r

9ZiErJKjDKyospCH+EQr+zGxVES3M+HYWu4bWumZoFP9mUMH4WGqAEec75HTzBjntDUmbHglOLiN

/AaFB0JmPiVub4sxrSAz1g1T7RzzMuWHjwhsJs89wEqcJe7nmd7iEAQ02dipPdxnWKfh0l2EUBwY

kjHZP8gdJkBlHjgJtkpqMpHc8aP92qqBGIZZnrXTbwM2rn7Gpf0HdyR7T8RrXpqbBPbpdiJj7NIt
rDnpxUjSxM+HtRjY5mMjV/0xHEgobmHW63bpuw==
From: British Gas Energy 
Date: Fri, 08 Dec 2023 05:03:30 -0600
X-Spam-ASN: AS14340 161.71.0.0/17

They both passed DKIM, and both came from Salesforce IP space. From
161.71.69.229 to be exact.

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

-- 
GLLUG mailing list
GLLUG@mailman.lug.org.uk
https://mailman.lug.org.uk/mailman/listinfo/gllug


Re: [GLLUG] IPv6 address allocation changes

2023-07-24 Thread Andy Smith via GLLUG
Hello,

On Mon, Jul 24, 2023 at 12:19:39PM +0100, John Hearns via GLLUG wrote:
> Is it a shaggy dog story that the CIA own the Class A 10.X.X.X block?

I doubt there is any factual evidence regarding this that could be
looked up in literally seconds, so sure, why not?

Regards,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

-- 
GLLUG mailing list
GLLUG@mailman.lug.org.uk
https://mailman.lug.org.uk/mailman/listinfo/gllug


Re: [GLLUG] IPv6 address allocation changes

2023-07-22 Thread Andy Smith via GLLUG
On Sat, Jul 22, 2023 at 09:24:15PM +, Andy Smith via GLLUG wrote:
> It's not really a thing to worry about. Unless you have an ISP that
> considers your assignment to be dynamic.

Oh, but have you seen yggdrasil? It's a mesh VPN that will provide a
static IPv6 /128 and /64 to each of your nodes, and your nodes can
opportunistically peer with each other so that local traffic can
remain local. It's a bit like Tailscale except that it's free and
involves no central authority.

You could build same out of Wireguard and BGP, but most people don't
want to go to that much effort.


https://changelog.complete.org/archives/10478-easily-accessing-all-your-stuff-with-a-zero-trust-mesh-vpn

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

-- 
GLLUG mailing list
GLLUG@mailman.lug.org.uk
https://mailman.lug.org.uk/mailman/listinfo/gllug


Re: [GLLUG] Comments please

2023-07-22 Thread Andy Smith via GLLUG
Hello,

On Sat, Jul 22, 2023 at 05:36:40PM +0100, bap--- via GLLUG wrote:
> 6.By making the NHS the go-to people for large-scale healthcare
> systems position them as the obvious people to implement universal
> healthcare in the USA when the time is right
> 7.Make the NHS revenue-neutral. 

A great plan that involves merely making enemies of:

- The UK government
- Microsoft
- The entire US health insurance industry

😀

I don't want to be negative about someone else's idealistic goal. It
would be great if you succeeded.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

-- 
GLLUG mailing list
GLLUG@mailman.lug.org.uk
https://mailman.lug.org.uk/mailman/listinfo/gllug


Re: [GLLUG] IPv6 address allocation changes

2023-07-22 Thread Andy Smith via GLLUG
Hi Chris,

On Sat, Jul 22, 2023 at 02:24:52PM +0100, Chris Bell via GLLUG wrote:
> From www.ripe.net/publications/docs/ripe-682
> The minimum IPv6 address block allocated to end users is expected to be a /48.
> The minimum IPv6 address allocation to an ISP is a /32, but they are only 
> leased, and any block could be re-assigned at any time after 24 months to 
> simplify overall allocations, so in effect all are dynamic addresses.

The word "lease" does not appear in the link you provide.

The remarks about being reassigned after 24 months relate to
"scarce network resources" such as IPv4 and 16-bit ASNs. Not
(currently) IPv6 allocations.

The text about re-assignments relates to *limiting* the passing on
of IPv4 allocations, not encouraging any sort of movement of IPv6
allocations as you imply. The reason being that there is currently a
lot of money in trading scarce IPv4 blocks.

The document goes on to say that mergers of organisations could
still result in re-assignments, which is only logical: if your
hosting company is bought by another company, the buyer gets to
decide what to do with their new supply of IP addresses, and that
may not include continuing to allow you as their customer to use
them.

In reality Regional Internet Registries like RIPE do not ever take
away IP allocations made to their clients, the Local Internet
Registries, barring extreme issues of non-payment or fraud. Not even
extremely ill-considered granting of too much resource is ever
corrected, because it is on dodgy legal ground to do so.

What LIRs do with their customers is a different matter, and though
it may be business suicide to force your customers to renumber, some
do it sometimes.

If your ISP or hosting company provides you with an IPv6 assignment,
they might consider it dynamic and change it regularly, or they
might consider it largely permanent (barring sale of the company
etc.). It is totally up to them.

Address allocations made by RIR to a LIR are considered permanent.
If you never want to worry about this, your org should become a LIR.
There is no policy of RIPE for chopping and changing IPv6
allocations to their LIRs, nor making their LIRs do that with the
assignments they make to their customers.

> Are applications expected to automatically accept a random change to the 
> first 
> few (up to 48) bits but keep the following bits up to the standard /64 to 
> retain a possibly huge network structure? Should the first 64 bits be 
> automatically re-calculated as a precaution?

It was/is the IETF dream that the entire network part could change
relatively often leaving the last 64 bits static and that apps
should just cope, but in reality this doesn't work that well with
most software.

It's not really a thing to worry about. Unless you have an ISP that
considers your assignment to be dynamic.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

-- 
GLLUG mailing list
GLLUG@mailman.lug.org.uk
https://mailman.lug.org.uk/mailman/listinfo/gllug


Re: [GLLUG] JOB | Startup in London, UK (Blockchain, Cryptocurrency)

2023-07-14 Thread Andy Smith via GLLUG
Hi,

On Fri, Jul 14, 2023 at 10:07:02PM +0100, Martin A. Brooks via GLLUG wrote:
> On 2023-07-14 18:42, Martin A. Brooks via GLLUG wrote:
> > On 2023-07-14 16:06, James Tobin via GLLUG wrote:
> > > Hello,
> > 
> > Fuck off, James.
> 
> Just to add to this: I'm not a list admin anymore but, if I were, this is
> now grounds for a permanent ban.

Who ARE the list's admins? I've Cc'd the -owner address here; are
you willing to identify yourselves and weigh in on this one?

Thanks,
Andy

PS Identical post from James Tobin now seen by me on the ansible
   list, Surrey LUG, Silicon Corridor LUG so I've no idea how many
   places James has broadcast it out to. What I do know is that
   James doesn't participate in any of those communities either,
   aside from sending their job ads.

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

> The optimum programming team size is 1.
Has Jurassic Park taught us nothing? — pfilandr

-- 
GLLUG mailing list
GLLUG@mailman.lug.org.uk
https://mailman.lug.org.uk/mailman/listinfo/gllug


Re: [GLLUG] JOB | Lead Linux Sysadmin (Edinburgh/London)

2023-03-14 Thread Andy Smith via GLLUG
Hello,

On Tue, Mar 14, 2023 at 09:49:11AM +, John Hearns via GLLUG wrote:
> We had endless wrangling about this in the early days. As I remember we had
> one problem recruiter.

And do you remember who that was?

James Tobin.

I guess he changed his mind about never posting here again.
https://mailman.lug.org.uk/pipermail/gllug/2009-January/043255.html

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

-- 
GLLUG mailing list
GLLUG@mailman.lug.org.uk
https://mailman.lug.org.uk/mailman/listinfo/gllug


Re: [GLLUG] Direct Fibre To The House

2022-08-29 Thread Andy Smith via GLLUG
Hello,

On Mon, Aug 29, 2022 at 03:08:08PM +0100, Chris Bell via GLLUG wrote:
> On Monday, 29 August 2022 13:40:54 BST aidangcole--- via GLLUG wrote:
> > Would using Headscale / Tailscale simply solve this without all the
> > routing hassle and admin ?
> 
> Sorry, not understood. I have had to use port forwarding over a single IPv4 
> address together with careful firewalling to do anything.

So, you are used to having a static IPv4 at home and using NAT to
forward ports on that IP to application servers within your home
network.

e.g. if your globally routable IPv4 were 1.2.3.4 and your
LAN was 192.168.123.0/24 maybe you NAT 1.2.3.4:80 to
192.168.123.4:80 so that the web server on 192.168.123.4 is
reachable from the public Internet as http://1.2.3.4/.

You now get native IPv6 but the problem is that it's a dynamic /48
of which the first /64 is automatically set up on your LAN, but you
don't know which /48 it will be a part of and this can change at any
time.

First of all I want to reiterate that your goal is quite niche. Most
people are not hosting things at home, and don't want to host things
at home. The need for IPv6 connectivity is like the need for basic
Internet connectivity. It's so they can consume content that's out
on the Internet, not run a datacentre at home.

So, your most sensible options in my opinion are:

a) Rent a server with static IPv6 assignment and use that as your
   front end, not the IPv4/IPv6 at your home

   This server might be a VM which at the low end would only be a
   few dollars a month. Or it might be in one of the popular clouds.
   Not literally a bare metal server, though that would work too.

   You would VPN to it from your home using something like
   wireguard, either directly or with a helper like the already
   mentioned tailscale which makes things very simple.

   Your home plus an arbitrary number of other locations connect
   to your server and it does not matter that your home has dynamic
   IPs because your home identifies itself to the VPN server (and
   vice versa) by certificates.

   You carve out /64s from the IPv6 assignment on your server, for
   example maybe you have:

2001:db8:1234::/48 - Hosting provider assignment to your server
2001:db8:1234:0::/64 - things on your server
2001:db8:1234:1::/64 - your home
2001:db8:1234:2::/64 - another site
2001:db8:1234:3::/64 - third site
.
.
2001:db8:1234:::/64 - 65,536th site

   So there's a scheme for up to 65,536 globally routable networks
   under one IPv6 prefix with each underlying network being v4, v6,
   static or dynamic, doesn't matter. You can do it right now. Each
   end site can change provider and connectivity method any number
   of times but its global v6 assignment remains the same as long as
   you keep your server.

   e.g. http://[2001:db8:1234:1::4]/ hits your server, packets go
   down the VPN to your home, served off of the same machine as
   192.168.123.4 (or whatever its ISP-supplied v6 address is, and
   obviously it would usually be a DNS name not a bare IPv6 address
   used in the browser).

   Downside is a star topology with all the traffic going through
   your server. A further consequence of that is that you would have
   to take steps to ensure that the things at each site are usable
   locally to the site even if your server is not reachable by them.
   Obviously you don't want to be unable to control your heating and
   lights or manage your CCTV just because your VM at Linode is
   unreachable! This isn't an insurmountable problem, just one that
   too few people think about.

b) Wait until there's enough choice of connectivity provider that
   you can pay extra for static IPv6 assignment at home

   Downsides:
- Probably costs more than the VM
- May not be available at all
- Might be harder to reliably serve things from your home than
  from a VM or bare metal server in a purpose built datacentre
- Renumber every time you change domestic ISP unless you become
  a member of RIPE NCC (€1,400/year), be allocated a v6
  network of your own and then find a broadband ISP that will
  announce it for you (more expense, hard)¹.

It's possible that things could have been different if IPv6 had
gained traction before the whole world was put behind IPv4 NAT to
conserve address space, but it wasn't, so statistically no one² is
running globally routable home networks with real services on them.
All the IoT stuff has been built with that in mind and it's extra
effort to self-host.

Cheers,
Andy

¹ It is also much easier and cheaper to find a VM provider that will
  announce your own network(s) than it is to find a home broadband
  supplier that will do the same.

² Yes, I am, and I'm sure plenty of other people on this list are,
  because that's our thing. But in terms of customer base for any
  commercial product or service, it's not really a market. They
  expect the consumer to use their 

Re: [GLLUG] Direct Fibre To The House

2022-08-29 Thread Andy Smith via GLLUG
Hello,

On Mon, Aug 29, 2022 at 01:08:07PM +0100, Martin A. Brooks via GLLUG wrote:
> On 2022-08-29 12:33, Andy Smith via GLLUG wrote:
> > I would expect most domestic broadband to come with non-static IPv6,
> > yes.
> > For no other reason than that a static v6 assignment is useful to a
> > minority, and therefore worth charging extra for.
> 
> Speaking for two ISPs I use, Zen and AA, both allocate static IPv6 blocks by
> default at no additional cost.

Rather niche suppliers though, even Zen. Surely 90%+ of UK
subscribers will be with the big 5 providers.

I am an A&A customer myself.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

-- 
GLLUG mailing list
GLLUG@mailman.lug.org.uk
https://mailman.lug.org.uk/mailman/listinfo/gllug


Re: [GLLUG] Direct Fibre To The House

2022-08-29 Thread Andy Smith via GLLUG
Hi Chris,

On Mon, Aug 29, 2022 at 11:40:15AM +0100, Chris Bell via GLLUG wrote:
> There are many full fibre suppliers, so is this the normal for UK domestic 
> customers?

I would expect most domestic broadband to come with non-static IPv6, yes.
For no other reason than that a static v6 assignment is useful to a
minority, and therefore worth charging extra for. That's not what
was intended by the designers of IPv6, but it is the commercial
reality.

> An IPv6 dynamic /48 allocation appears to me to make no sense, but
> introduces direct access restrictions affecting security
> monitoring, CA certification, etc.

Why is it any different than a dynamic IPv4 address for all of these
things?

If you don't like the v6 addresses on your LAN changing you can use
a network from ULA space¹ with a default gateway out to the v6
Internet for any other destination.

Cheers,
Andy

¹ https://blog.apnic.net/2020/05/20/getting-ipv6-private-addressing-right/

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

-- 
GLLUG mailing list
GLLUG@mailman.lug.org.uk
https://mailman.lug.org.uk/mailman/listinfo/gllug


Re: [GLLUG] LVM / KVM Question

2022-02-15 Thread Andy Smith via GLLUG
Hi,

On Tue, Feb 15, 2022 at 10:19:32AM +, Ken Smith via GLLUG wrote:
> I'm contemplating a system where I pass a LVM LV through to a KVM VM.
> 
> On the host I'm thinking that I could do a backup of the LV using a LVM
> snapshot.
> 
> What am I missing, is this a mad idea?

Many people do this. However:

- Backed up data from the snapshot won't contain working data from
  within the memory of the processes in the VM, so if you restored
  from it, it would be like coming up after a power loss.

- Lots of other KVM disk backends can do snapshots so LVM isn't
  required to do this.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

-- 
GLLUG mailing list
GLLUG@mailman.lug.org.uk
https://mailman.lug.org.uk/mailman/listinfo/gllug


Re: [GLLUG] irssi and ssl

2021-11-16 Thread Andy Smith via GLLUG
Hello,

On Tue, Nov 16, 2021 at 04:13:55PM +, Henrik Morsing wrote:
> On Tue, Nov 16, 2021 at 03:50:34PM +, Andy Smith wrote:
> > $ openssl s_client -connect irc.aachat.net:6697
> 
> Sorry, I remembered wrong. Which is good, because tried showed it
> didn't work. Straced it reveled that /etc/ssl had the wrong
> permissions (750 instead of 755) and it now works! Awesome.

Glad you found the issue! A pity you didn't see/try it when John
Edwards suggested it yesterday in the very first reply you got
though - would have made for a much shorter thread. :)

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

-- 
GLLUG mailing list
GLLUG@mailman.lug.org.uk
https://mailman.lug.org.uk/mailman/listinfo/gllug

Re: [GLLUG] irssi and ssl

2021-11-16 Thread Andy Smith via GLLUG
Hi Henrik,

On Tue, Nov 16, 2021 at 03:44:16PM +, Henrik Morsing wrote:
> First one, yes, I get expected output.

So if this works:

$ openssl s_client -connect irc.aachat.net:6697

what is its output?

And if it does work, that kind of suggests the problem is in your
irssi configuration doesn't it? (since your openssl client is able
to negotiate and also your irssi on a different computer is able to
connect)

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

-- 
GLLUG mailing list
GLLUG@mailman.lug.org.uk
https://mailman.lug.org.uk/mailman/listinfo/gllug

Re: [GLLUG] irssi and ssl

2021-11-16 Thread Andy Smith via GLLUG
Hello,

On Tue, Nov 16, 2021 at 03:19:35PM +, Henrik Morsing via GLLUG wrote:
> Wow, just tried from my home server which I always keep on the
> same Debian version as my cloud server, and it went straight in!
> At least I have something to compare to now.

So you now have a machine that it works on and a machine which it
doesn't…

Did you ever try the openssl s_connect test you were given before?

$ openssl s_client -connect irc.aachat.net:6697

and does it work for a web site using a LE cert? e.g.

$ openssl s_client -connect bitfolk.com:443

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

-- 
GLLUG mailing list
GLLUG@mailman.lug.org.uk
https://mailman.lug.org.uk/mailman/listinfo/gllug

Re: [GLLUG] irssi and ssl

2021-11-16 Thread Andy Smith via GLLUG
Hi Henrik,

On Tue, Nov 16, 2021 at 08:26:03AM +, Henrik Morsing via GLLUG wrote:
> Same for Libera:
> 
> 08:25 -!- Irssi: warning Could not verify TLS servers certificate: unable to 
> get
>   local issuer certificate

Sorry if I've missed this in the thread, but what version of Debian
is this?

On Debian 8 I found I had to disable the mozilla/DST_Root_CA_X3.crt
to force usage of the other Let's Encrypt root. I did that by doing:

$ sudo dpkg-reconfigure ca-certificates

then de-selecting mozilla/DST_Root_CA_X3.crt

Updating certificates in /etc/ssl/certs...
0 added, 1 removed; done.

I then was able to connect to things with a Let's Encrypt cert.

That was for web services though; I don't use any Debian 8 machines
for connecting to IRC. On the more recent Debian host that I use for
IRC I have no problem connecting to libera or aachat with TLS.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

-- 
GLLUG mailing list
GLLUG@mailman.lug.org.uk
https://mailman.lug.org.uk/mailman/listinfo/gllug

Re: [GLLUG] basic IPv6 questions

2021-10-04 Thread Andy Smith via GLLUG
Hi,

On Sun, Oct 03, 2021 at 09:12:46PM +0200, Carles Pina i Estany wrote:
> If the Raspberry pi + BT router used SLAAC is this more or less what
> happens?
> -Raspberry pi sends a broadcast using NDP probably type "Router
> Solicitation (Type 133)"
> (https://www.rfc-editor.org/rfc/rfc4861.html#section-4.1)
> -Router probably answers with a "Router Advertisement (Type 134)"
> (https://www.rfc-editor.org/rfc/rfc4861.html#section-4.2)
> 
> The Router Advertisement includes the IP of the router (in the "Source
> Address"?)

On your network where the raspberry pi is located, if you do a
tcpdump you should see the periodic router advertisements from the
BT router:

# tcpdump -vni eth0 'icmp6 and ip6[40] == 134'

(change "eth0" for whatever interface name is the one that's on the
same network as the BT router)

All RA packets are ICMP (v6) and the type byte is at position 40
which is 134 as you mentioned above.

Use more -v or a -X to see full packet contents.

> When I had to setup a Linux box in a LAN I sometimes use
> isc-dhcp-server. If I wanted to setup ipv6 devices with SLAAC: what
> would be the way to go?

I'm afraid I don't have any experience with DHCPv6 as I've been
satisfied with SLAAC and static config, but I believe:

- SLAAC is only going to give you default gateway and
  auto-configuration of client's own address (client decides whether
  based on MAC or not)

- DHCPv6 is still needed if you need to learn nameservers or a
  static IPv6 address or any of the other things you usually put in
  DHCP

- There are extensions to DHCPv6 to also learn routes/gateway so it
  is possible to ignore SLAAC

> For example, the last time that I had to do this I used isc-dhcp-server
> for very basic things like:
> -Setup the DNS of the clients
> -For some of the clients a static assigned IP (e.g. host with MAC
> address X is always the IP Y)
> -Setup the gateway of the clients (some clients didn't have a gateway,
> some had a gateway)
> 
> Is this something that could be done using SLAAC? Or should be done with
> a DHCPv6 server?

Routing is for SLAAC (or static), everything else DHCPv6. This
article may be out of date now (4 years old) but it covers using
isc-dhcpd for v6 on a rapsberry pi:

https://blog.netpro.be/dhcpv6-configuration-isc-dhcp-server/

It seems to be saying that the binary supports EITHER v4 or v6 so yu
have to run two copies, copy the initscript etc. Possibly there's a
more elegant solution now.

If you are choosing IPv6 addresses then I think you need to either
do it by DHCPv6 or else statically configure it, as SLAAC can only
give you a stable but not customisable address. Addresses generated
by SLAAC are either:

- Stable but based on MAC

- Temporary, constantly changing

- Stable but based on local secret so not predictable

If you wanted to do something cute like say "the interface with mac
b8:27:eb:b0:9d:76 should also have IPv6 address
2a00:23c6:2c01:b801::443/64 because I will use it for a web server"
then I think you're going to either have to use DHCPv6 for that or
else configure it locally on that machine.

> To confirm:
> 
> Link local address: a private address like 192.168.0.0/24 (starting with
> fe80:: in ipv6). Valid only in the network segment, not routeable

Not quite, but you're close. There's a difference between link-local
addresses and private addresses.

In IPv4, 192.168.0.0/16 is one of the ranges reserved by RFC1918 for
private use. They are actually routable and can be used as private
intranet between multiple organisations in any way they like. Some
large organisations have multi-continent backbone all on private
IPv4 addresses.

IPv6 also has the concept of private-but-routable addresses, and
fc00::/7 is reserved for this:

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

It doesn't see much use because IPv6 is so plentiful that you may as
well use part of your globally routable assignment for this purpose.

So in IPv6 fc00::/7 would be the equivalent of the RFC1918 IPv4
reservations like 192.168/16, 172.16/12 or 10/8.

fe80::/10 by contrast is a *link-local* address. It is not routable,
so packets can only go to other devices on the same network segment.

IPv4 also has link-local addresses; they were defined in RFC6890 and
have the range 169.254/16. Some platforms do assign an IPv4
link-local address in the event that there is no DHCP and no static
configuration. It isn't seen very often. They similarly are meant to
be locally unique and not routable.

> > Your IID on your pi clearly isn't that, but it also doesn't have the
> > ff:fe or the flipped 7th bit, so it's not EUI-64. Looking at "ip -6
> > a" (short hand for "ip address show") might tell you some more info;
> > it will at least say whether the address is temporary or not.
> 
> 2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
> group default qlen 1000
> link/ether b8:27:eb:b0:9d:76 brd ff:ff:ff:ff:ff:ff
> inet6 2a00:23c6:2c01:b801:2817:ffe3:d3aa:5d8c/64 scope global dynamic 
> mngtmpaddr no

Re: [GLLUG] basic IPv6 questions

2021-10-03 Thread Andy Smith via GLLUG
Hi Carlos,

On Sun, Oct 03, 2021 at 02:57:51PM +0200, Carles Pina i Estany via GLLUG wrote:
> I have a Raspberry pi connected to a BT router that recently has
> "switched" to ipv6 only (yay?!). This is helping me to test a Gandi
> server ipv6 configuration.
> 
> Raspberry pi: /sbin/ifconfig eth0:

First of all you should get into the habit of using "ip address" and
"ip route" commands instead of "ifconfig" and "route".

The latter commands have been deprecated for many years now and
while they are probably showing you correct information here, they
do not always do so, as there is information in kernel data
structures that these commands haven't been updated to handle.
There's also settings that they can't set, for the same reason.

Finally, it is harder to talk about network configuration when using
the display from old tools. People who are particularly wedded to
"ifconfig" etc. sometimes argue that it's what they know and they
know it's showing them correct info, but in a situation where
seeking support from others the current tools need to be used so
everyone knows what they are looking at.

So, I understand that there may be a muscle memory issue with
immediately reaching for "ifconfig" etc — I experienced the same
myself and still do with some of the "netstat" replacements — but
there's nothing to be done about that except try to learn the new
tools!

> eth0: flags=4163  mtu 1500
> inet6 fe80::56d8:5a6c:fc11:16f1  prefixlen 64  scopeid 0x20
> inet6 2a00:23c6:2c01:b801:2817:ffe3:d3aa:5d8c  prefixlen 64  scopeid 
> 0x0
> ether b8:27:eb:b0:9d:76  txqueuelen 1000  (Ethernet)

> Gandi server: /sbin/ifconfig eth0:
> eth0: flags=4163  mtu 1500
> inet 213.167.241.144  netmask 255.255.254.0  broadcast 213.167.241.255
> inet6 2001:4b98:dc2:53:216:3eff:fe82:b1fb  prefixlen 64  scopeid 
> 0x0
> inet6 fe80::216:3eff:fe82:b1fb  prefixlen 64  scopeid 0x20
> ether 00:16:3e:82:b1:fb  txqueuelen 1000  (Ethernet)

> -inet6 2a00 and 2001 ipv6 addresses: they are global ipv6 routeable from
>  the internet (google.com is 20aa:..., dns.google is 2001:...).

Yes.

>  by the DHCP server of each network (or static configuration).

Yes, although dynamic IPv6 configuration is more often done by
StateLess Address Autoconfiguration (SLAAC) rather than DHCP. SLAAC
works through announcements by the network segment's router(s)
telling devices on that network segment which addresses they can
choose and what their default gateway should be.


https://en.wikipedia.org/wiki/IPv6_address#Stateless_address_autoconfiguration

DHCPv6 does exist though so it is possible that this is used in
addition or instead of SLAAC.

> -Any difference between 2a00 and 2001? Any other addresses like this?

They are conceptually as similar as 12.0.0.0/8 and 185.0.0.0/8 in
IPv4m, for example. Just different globally routable address blocks.
Out of the entire 128-bit space of IPv6 addresses, 2000::/3 has been
allocated so far for global unicast addresses, so every public
address you see should be in the range:

$ sipcalc 2000::/3
-[ipv6 : 2000::/3] - 0

[IPV6 INFO]
Expanded Address- 2000:::::::
Compressed address  - 2000::
Subnet prefix (masked)  - 2000:0:0:0:0:0:0:0/3
Address ID (masked) - 0:0:0:0:0:0:0:0/3
Prefix address  - e000:0:0:0:0:0:0:0
Prefix length   - 3
Address type- Aggregatable Global Unicast Addresses
Network range   - 2000::::::: -
  
3fff:::::::

http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml

> -From the server I would be able to ping
>  2a00:23c6:2c01:b801:2817:ffe3:d3aa:5d8c if BT wanted (can I ask them?
>  is it in the router configuration? Doing a traceroute I don't quite get
>  into the local home router IP, I don't think so)

In theory you or anyone should be able to ping
2a00:23c6:2c01:b801:2817:ffe3:d3aa:5d8c but there might be a
firewall in operation. It's probably a good idea if there is, as
that's on your LAN side of the link and you don't really want the
Internet to be able to talk directly to your router.

I'm afraid I've no idea if you are able to disable any such
firewalling or get BT to do anything about it.

> -fe80:: are local in the network IPs. For Gandi: this gets generated out
>  of the MAC address. And not for the Pi, why not? (how to set this up?)

Your pi:
> inet6 fe80::56d8:5a6c:fc11:16f1  prefixlen 64  scopeid 0x20
> ether b8:27:eb:b0:9d:76  txqueuelen 1000  (Ethernet)

Your server:
> inet6 fe80::216:3eff:fe82:b1fb  prefixlen 64  scopeid 0x20
> ether 00:16:3e:82:b1:fb  txqueuelen 1000  (Ethernet)

I think that your raspberry pi might be using stable privacy
addresses (RFC7217) to choose a random interface ID (IID) pe

Re: [GLLUG] IT does cost

2021-08-06 Thread Andy Smith via GLLUG
Hello,

On Fri, Aug 06, 2021 at 11:17:42AM +0100, Chris Bell via GLLUG wrote:
> I am not a developer, but would be interested in the implications
> and costs of writing and maintaining government software systems
> using Free Open Source Software compared with Microsoft.

To be honest I am so disillusioned with the level of corruption in
government that I can't see how there could ever be a level playing
field for open source software in this market.

Both the buyer (the government) and the vendor just seem to want to
find a way to move as much money from the public purse to the
private sector as possible. Neither seemingly has any interest in
the actual technology, the level of service provided or even whether
the company survives the length of the contract.

It just seems like a massive waste of time trying to prove that
there can be a better way of doing things when the contract is
always going to go to a pre-selected vendor that has close ties with
the people doing the selecting.

No doubt lots of it is Linux underneath, but let's not pretend that
has any level of interest for any decision maker. There's money to
be made here. :(

Cheers,
Andy

-- 
GLLUG mailing list
GLLUG@mailman.lug.org.uk
https://mailman.lug.org.uk/mailman/listinfo/gllug

Re: [GLLUG] IPv6 addresses

2021-07-18 Thread Andy Smith via GLLUG
Hello,

On Sun, Jul 18, 2021 at 10:33:03AM +0100, Chris Bell via GLLUG wrote:
> My sister has a relatively new domestic BT broadband connection. The IPv4 
> address was expected to be dynamic despite BT claiming to have sufficient 
> IPv4 
> addresses, while the IPv6 address so far has had a static /48 but dynamic 
> /64. 
> Is there a cost involved in providing a static address, or are UK customers 
> considered to be incapable of safely using a static address? Perhaps it just 
> allows them to charge extra for a "business" broadband.

Correct, in most cases it's an artificial segmentation of the market
in order to charge more money. There's no technical benefit and
quite a few downsides.

In some cases the ISP has more customers or is projected to have
more customers than they have IPv4 addresses, so some of them have
to be CGNAT, or CGNAT will have to be introduced soon, so it is wise
not to let people get used to having a dedicated IPv4 address.

There is no such issue with IPv6 so make the main prefix (in your
example a /48) static is sensible. The end device /64s within that
are often dynamic as a security/privacy measure though ideally this
is controlled by the customer's equipment not the provider's.

In Switzerland some can now get 25Gbit/s symmetric fibre with
static IPv4, static IPv6 and HD TV thrown in, for about £50/mo:

https://www.init7.net/en/internet/fiber7/

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

-- 
GLLUG mailing list
GLLUG@mailman.lug.org.uk
https://mailman.lug.org.uk/mailman/listinfo/gllug

Re: [GLLUG] Power control over IP

2021-06-04 Thread Andy Smith via GLLUG
Hello,

On Fri, Jun 04, 2021 at 11:50:21AM +0200, stuart taylor via GLLUG wrote:
> > Sent: Tuesday, June 01, 2021 at 4:49 PM
> > From: "Andy Smith via GLLUG" 
> > I don't know what CPUs are in Stuart's IBM x3250s. If you can let us
> > know Stuart I can tell you how a 2GHz Xeon D-1540 compares.
> 
> 
> they are xenon processors, 3050 i think.

This should prove fun reading then 😀


https://www.cpubenchmark.net/compare/Intel-Xeon-3050-vs-Intel-Xeon-D-1540/1177vs2507

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

-- 
GLLUG mailing list
GLLUG@mailman.lug.org.uk
https://mailman.lug.org.uk/mailman/listinfo/gllug

[GLLUG] Xeon D servers (Was: Re: Power control over IP)

2021-06-01 Thread Andy Smith via GLLUG
Hi John,

On Tue, Jun 01, 2021 at 07:46:25PM +0100, John Hearns via GLLUG wrote:
> I did like the Xeon-D at that time. I wanted to position them as servers
> for bioinformatics (gene sequencing).
> I never quite achieved that and do regret it.

They've been lovely little servers for the last 5 years, been very
happy with them, and the short depth meant it was refreshing to be
able to fit one in my backpack and rock up to Telehouse on foot!
They also only draw about 48VA at idle. The chassis is only 287mm
deep:

https://www.supermicro.com/en/products/chassis/1U/510/SC510T-203B
https://www.supermicro.com/en/products/motherboard/X10SDV-F

But there's no upgrade path and at 1 socket / 8 cores @2GHz / 128G
RAM per 1U they are just not dense enough any more, even for someone
like me who is not trying to do anything particularly dense. :)

https://ibin.co/63ukcXdxuCBR.jpg

Maybe still useful for someone.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

-- 
GLLUG mailing list
GLLUG@mailman.lug.org.uk
https://mailman.lug.org.uk/mailman/listinfo/gllug

Re: [GLLUG] Power control over IP

2021-06-01 Thread Andy Smith via GLLUG
Hello,

On Tue, Jun 01, 2021 at 04:37:27PM +0100, James Courtier-Dutton via GLLUG wrote:
> If you are a charity, it might be worth asking some service providers
> if they would donate a VM for your use also.

I'll probably have some Supermicro Xeon D-1540-based systems that
are otherwise going to computer recycling soon. So if anyone wants
them they can have them for free - it will be collect from Telehouse
Docklands. These are 2015 vintage. As they're proper rackmount
servers they do have a decent BMC that supports remote power
management and console.

I don't know what CPUs are in Stuart's IBM x3250s. If you can let us
know Stuart I can tell you how a 2GHz Xeon D-1540 compares.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

-- 
GLLUG mailing list
GLLUG@mailman.lug.org.uk
https://mailman.lug.org.uk/mailman/listinfo/gllug

Re: [GLLUG] Two factor authentication

2021-05-29 Thread Andy Smith via GLLUG
Hello,

On Sat, May 29, 2021 at 04:56:32PM +0200, stuart taylor via GLLUG wrote:
> I am thinking of deploying two factor authentication on our
> servers, but some of the other admins cannot get a mobile signal
> when they are at home. Is there any other way I can do this, or a
> better way of improving authentication?

The only multi-factor authentication method I am aware of that
requires a mobile signal is SMS, and that is a really poor MFA
method.

Notably a TOTP solution doesn't need any network access except at
the initial setup time when the service tells you your key. Which
even that could be avoided if you did it by post or something!

Here's an example of an open source TOTP with PAM support which
works in any client that supports TOTP (not tied to Google in any
way):

https://wiki.archlinux.org/title/Google_Authenticator

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

-- 
GLLUG mailing list
GLLUG@mailman.lug.org.uk
https://mailman.lug.org.uk/mailman/listinfo/gllug

Re: [GLLUG] Using IPv6 addresses with Debian

2021-03-11 Thread Andy Smith via GLLUG
Hi Chris,

On Thu, Mar 11, 2021 at 03:14:42PM +, Chris Bell via GLLUG wrote:
> I am using Debian 10 Buster on various computers including RaspberryPi and 
> find 
> that I can manually add addresses to a running computer, but if I attempt to 
> configure multiple addresses only the last is accepted, and all but one is 
> lost 
> after a reboot.

I don't see a concrete question in your email, but for what it's
worth I add multiple IPv6 addresses on Debian by using pre-up hooks
in the /etc/network/interfaces file, e.g.:

iface eth0 inet6 static
address 2001:ba8:1f1:f019::2
netmask 64
gateway fe80::fcff::feff:
pre-up ip -6 addr add 2001:ba8:1f1:f019::3/64 dev $IFACE preferred_lft 0
pre-up ip -6 addr add 2001:ba8:1f1:f019::4/64 dev $IFACE preferred_lft 0

The "preferred_lft 0" bit is so that the addresses are present and
usable for daemons to bind to, but will never be used as a source
address for outgoing traffic. Without that, the last added address
will be used as the source address.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

-- 
GLLUG mailing list
GLLUG@mailman.lug.org.uk
https://mailman.lug.org.uk/mailman/listinfo/gllug

[GLLUG] Debian network interface boot configuration

2021-01-30 Thread Andy Smith via GLLUG
Hi Henrik,

Apologies for the broken threading; I seem to have accidentally
deleted your original message.

Your interfaces file should say "inet6" not "inet". i.e.:

iface eth3 inet6 static

Cheers,
Andy

-- 
GLLUG mailing list
GLLUG@mailman.lug.org.uk
https://mailman.lug.org.uk/mailman/listinfo/gllug

Re: [GLLUG] Failing DNS queries

2021-01-08 Thread Andy Smith via GLLUG
Hello,

On Sat, Jan 09, 2021 at 12:59:17AM +, Tim Woodall via GLLUG wrote:
> 359   173.231.186.139 (.): view external: query failed (REFUSED) for 
> ./IN/ANY at ../../../bin/named/query.c:7144

> is this some sort of DNS amplification that I've not heard of

Probably not. They are probably looking for open resolvers to use in
DNS amplification DDoS attacks.

> and do I need to do something different?

I'd firewall it off (with a DROP) except for networks that are
supposed to be using it, and not bother looking at the logs unless
it became problematic levels of traffic.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

-- 
GLLUG mailing list
GLLUG@mailman.lug.org.uk
https://mailman.lug.org.uk/mailman/listinfo/gllug

Re: [GLLUG] nginx oops!

2020-11-29 Thread Andy Smith via GLLUG
Hello,

On Sun, Nov 29, 2020 at 01:46:34PM +, MJ via GLLUG wrote:
>  error_log /var/log/nginx/dspr-error.log;

Anything interesting in that log file?

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

-- 
GLLUG mailing list
GLLUG@mailman.lug.org.uk
https://mailman.lug.org.uk/mailman/listinfo/gllug

Re: [GLLUG] IP address problems.

2020-11-12 Thread Andy Smith via GLLUG
Hi Chris,

It's difficult to respond substantively to your email as it doesn't
appear to contain a question, so not clear exactly what you want
help with, but…

On Thu, Nov 12, 2020 at 11:44:39AM +, Chris Bell via GLLUG wrote:
> I have tried entering all IPv4 and IPv6 addresses in /etc/network/interfaces 
> but with inconsistent IPv6 results

…I've been doing this for years and it works fine for me. Perhaps
you could give an example of what exactly doesn't work for you in
this regard?

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

> I'd be interested to hear any (even two word) reviews of their sofas…
Provides seating.— Andy Davidson

-- 
GLLUG mailing list
GLLUG@mailman.lug.org.uk
https://mailman.lug.org.uk/mailman/listinfo/gllug

Re: [GLLUG] why is adduser unknown command in Debian 10.4?

2020-09-01 Thread Andy Smith via GLLUG
Hello,

On Tue, Sep 01, 2020 at 04:01:04PM +, MJ via GLLUG wrote:
> desktop@desktop:~$ su
> Password: 
> root@desktop:/home/desktop# adduser desktop dialout
> bash: adduser: command not found
> root@desktop:/home/desktop# 

Most likely /usr/sbin isn't in your path as "su" doesn't do that any
more.

https://wiki.debian.org/NewInBuster

== Changes

* The su command in buster is provided by the util-linux source
  package, instead of the shadow source package, and no longer
  alters the PATH variable by default. This means that after doing
  su, your PATH may not contain directories like /sbin, and many
  system administration commands will fail.

> This is LPC 101 standard stuff?!

Rote learning goes out of date. Working out how to diagnose a
"command not found" error is more valuable.

$ command -v adduser
/sbin/adduser
# Oh, /usr/sbin is in my user's path then. Because I set that on purpose
$ PATH= command -v adduser
$ apt-file search bin/adduser
adduser: /usr/sbin/adduser
$ dpkg -L adduser | grep bin
/usr/sbin
/usr/sbin/adduser
/usr/sbin/deluser
/usr/sbin/addgroup
/usr/sbin/delgroup
$ ls -lah /usr/sbin/adduser
-rwxr-xr-x 1 root root 34K Sep 15  2018 /usr/sbin/adduser

So, PATH issue.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

-- 
GLLUG mailing list
GLLUG@mailman.lug.org.uk
https://mailman.lug.org.uk/mailman/listinfo/gllug

Re: [GLLUG] Openssl and certificates

2020-07-28 Thread Andy Smith via GLLUG
Hello,

On Tue, Jul 28, 2020 at 09:47:51AM +0100, Chris Bell via GLLUG wrote:
> Openssl makes it easier to create my own CA and issue certificates for local 
> boxes with specified uses such as WWW and EMAIL, but I am not clear on the 
> best 
> approaches for multiple domains and boxes. I have dedicated individual boxes 
> to use as web server, email gateway, and email server, and multiple boxes for 
> each job to enable online backup and offline upgrades. Should individual 
> certificates be created for individual boxes or should the same certificate 
> be 
> shared between all boxes allocated for each individual job?

I don't think TLS concerns itself with what particular piece of
hardware is involved, it's about what is terminating the TLS
conversation for a given name.

If the conversation for foo.example.com could end up at any one of
several hosts then all hosts need the same TLS key material. If
you're terminating the conversation on a single load balancer with
20 hosts behind it but you're not talking TLS between the load
balancer and the hosts, then only the load balancer needs the key
material. If you have an active/passive pair of load balancers to
provide redundancy then both need the key material. And so on.

I create them with Let's Encrypt and have config management renew
them and push them out to where they need to be, so it doesn't
really matter how many there are.

If you had a web site on https://example.com/ I don't think you
would be wanting to call your mail server also example.com, so the
question of whether to share the key material doesn't arise. But
let's say for argument's sake that your mail server calls itself
mail.example.com and you also have webmail on
https://mail.example.com/. Should those two things share the same
key material?

With config management it is almost as easy to have them have unique
key material as it is to have them share. For long-lived keys there
is an argument to have them be separate so as to have fewer copies
that could be mislaid, but in the Let's Encrypt age the certs are
renewed every three months so that is less of a concern.

Also whether to use a single wildcard cert for everything under
example.com.

With frequent renewal I think you could argue either way.

I'd be more concerned about automation and only then think about
whether to use one or many or wildcard certs for the same name.

If the names are not valid outside your local network (e.g. you
expect users to connect to private DNS names like
https://admin.mycorp/) then you can't use Let's Encrypt and have to
do your own CA, which does make things a lot more of a faff. I tend
to argue for things being in the public DNS for this reason, as at
least then you can do ACME DNS-01.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

-- 
GLLUG mailing list
GLLUG@mailman.lug.org.uk
https://mailman.lug.org.uk/mailman/listinfo/gllug

Re: [GLLUG] Checking mail server configuration specifically for IPv4

2020-05-30 Thread Andy Smith via GLLUG
Hello,

On Sat, May 30, 2020 at 04:23:44PM +0100, John Winters via GLLUG wrote:
> I tend to use check-a...@verifier.port25.com to diagnose these things but
> I've hit a problem.  Both my mail server and theirs are fully IPv6 enabled,
> and all is good in IPv6.

What if you forced your mail server to use an IPv4 address when
talking to verifier.port25.com? Here's how to do it in Exim:


https://github.com/Exim/exim/wiki/How-to-force-IPv4-connections-for-specific-domains-if-IPv6-is-enabled

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

> I'd be interested to hear any (even two word) reviews of their sofas…
Provides seating.— Andy Davidson

-- 
GLLUG mailing list
GLLUG@mailman.lug.org.uk
https://mailman.lug.org.uk/mailman/listinfo/gllug

Re: [GLLUG] Systemd on Debian

2020-05-23 Thread Andy Smith via GLLUG
Hello,

On Sat, May 23, 2020 at 09:07:01AM +0100, Chris Bell via GLLUG wrote:
> with the correct prefix used for sending and receiving.

In case it helps, I am often in the situation where a host has a
general purpose v6 address and several "service addresses" that are
only used as listening addresses for different services on the host.

I don't like outgoing packets to source from one of those service
addresses, but the default Linux behaviour is to use the last added
address on the interface as a source address.

There are two easy ways to influence this. One way is to add the
desired source address with a longer prefix, e.g. /128. If all
others are shorter prefix than this, e.g. /64s then the /128 will be
preferred.

The way I like better is to add the service addresses with a
preferred_lft of 0 like:

# ip addr add 2001:db8::1/64 dev $IFACE preferred_lft 0

That would then show up as "deprecated" in the "ip -6 addr" list,
which prevents it being used for any source address nut doesn't
interfere with it receiving packets addressed to it.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

-- 
GLLUG mailing list
GLLUG@mailman.lug.org.uk
https://mailman.lug.org.uk/mailman/listinfo/gllug

Re: [GLLUG] Systemd on Debian

2020-05-23 Thread Andy Smith via GLLUG
Hello,

On Sat, May 23, 2020 at 10:07:24AM +0100, James Courtier-Dutton via GLLUG wrote:
> On Sat, 23 May 2020, 09:07 Chris Bell via GLLUG, 
> wrote:
> > I am trying to assign IPv4 and IPv6, with named local IP
> > addresses to individual networks for local access only,

> I am curious. Why do you think ipv6 link local address is useful for what
> you are trying to use it for?

The above is the only reference to "local" that I find and I didn't
take it as meaning strictly link-local. They could just be global
scope addresses that are only used internally. But in case it was
wanted to use addresses that cannot be globally routed, there is the
Unique Local Address range which is intended to be like RFC1918 but
for IPv6:

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

So in that case OP should pick some random block within fc00::/7.

But if OP has been assigned some stable prefix by the tunnel broker
then I would think it is perfectly fine to use a subnet of that for
internal addressing, with appropriate firewalling.

Perhaps there is a desire to keep the same internal addresses even
if the tunnel broker supplier were to change.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

-- 
GLLUG mailing list
GLLUG@mailman.lug.org.uk
https://mailman.lug.org.uk/mailman/listinfo/gllug

Re: [GLLUG] Systemd on Debian

2020-05-22 Thread Andy Smith via GLLUG
Hi,

On Fri, May 22, 2020 at 04:57:15PM +0100, Chris Bell via GLLUG wrote:
> Systemd attempts to rule the world of Debian Buster.

The usual way to define your network in Debian is still ifupdown as
configured by /etc/network/interfaces so it seems to me that you are
the one choosing to use systemd-networkd for ruling your world.

> man systemd.network says

[…]

> [ADDRESS] SECTION OPTIONS
> 
>Label=
>An address label.
> 
> 
> but there is no indication whether that should be a numerical reference or a 
> text string label such as DMZ.

It can (and for compat should) be a text string; it is the direct
equivalent of "ip address … label …". If you look in man ip-address:

label NAME
Each address may be tagged with a label string.  In order to
preserve compatibility with Linux-2.0 net aliases, this
string must coincide with the name of the device or must be
prefixed with the device name followed by colon.

An IPv6label on the other hand is a completely different thing. It
is a source address selection mechanism, like /etc/gai.conf but in
the kernel. It's an interface to ip addrlabel which as you'll note
is at a sompletely different command level to "ip address …". So the
man page for that in iputils terms is man ip-addrlabel.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

-- 
GLLUG mailing list
GLLUG@mailman.lug.org.uk
https://mailman.lug.org.uk/mailman/listinfo/gllug

Re: [GLLUG] How worried should I be ...

2020-05-22 Thread Andy Smith via GLLUG
Hello,

On Fri, May 22, 2020 at 04:37:57PM +0100, Alain D D Williams via GLLUG wrote:
> Should I take this as a warning and look to replace the machine or just shrug 
> my
> shoulders & mutter something about cosmic rays ?
>
> Message from syslogd@mint at May 22 07:27:09 ...
>  kernel:[Hardware Error]: MC4 Error (node 0): L3 data cache ECC error.
> 
> Message from syslogd@mint at May 22 07:27:09 ...
>  kernel:[Hardware Error]: Error Status: Corrected error, no action required.

The L3 cache is inside the CPU. It can be a faulty CPU, I think it
could possibly also be faulty RAM if you do not have ECC RAM
(otherwise problem would have been detected in the RAM not the L3
cache). Either way it is a single bit flip detected by ECC in the
cache and corrected.

If you can shut the machine down I would run a few passes of
memtest. That will hopefully spot any RAM problems.

If the RAM comes up clean but it keeps happening, I would really
suspect the CPU and plan for a replacement soon.

If the RAM comes up clean and it never happens again well, then yes
it could be cosmic rays or similar. I have seen this sort of thing
only a couple of times in 20 years; only one of those times did it
not soon get worse. It's not really enough data to say whether you
are in for a bad time.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

-- 
GLLUG mailing list
GLLUG@mailman.lug.org.uk
https://mailman.lug.org.uk/mailman/listinfo/gllug

Re: [GLLUG] Plusnet and BT

2020-05-12 Thread Andy Smith via GLLUG
Hello,

On Tue, May 12, 2020 at 10:26:11AM +0100, Chris Bell via GLLUG wrote:
> Is this the best that they can manage after so many promises?

No it'd all they need to manage for those who will buy the cheapest
and lump it.

Switch to a decent provider like Andrews&Arnold or Zen, enjoy static
IPv4 and IPv6 netblocks. Life is too short.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

> I'd be interested to hear any (even two word) reviews of their sofas…
Provides seating.— Andy Davidson

-- 
GLLUG mailing list
GLLUG@mailman.lug.org.uk
https://mailman.lug.org.uk/mailman/listinfo/gllug

Re: [GLLUG] Link two RAIDs in one LVM?

2020-05-11 Thread Andy Smith via GLLUG
Hello,

On Mon, May 11, 2020 at 10:22:46AM +0100, John Winters via GLLUG wrote:
> On 11/05/2020 10:02, James Roberts via GLLUG wrote:
> >I haven't reviewed all the recent replies, but is there any reason why you
> >can't add the the two new disks of the same size and migrate from RAID 1
> >to RAID 10
> 
> Yes

I actually think it is possible and is a reasonable plan, though
backups will still be advised. I didn't suggest this at first
because initially we thought there were unequal-sized devices (4T
and 8T).

I believe modern mdadm can reshape a RAID-1 into a RAID-0 then a
RAID-0 into a RAID-10 and then add extra devices.

https://www.berthon.eu/2017/converting-raid1-to-raid10-online/

There will be a scary time when it is RAID-0 and therefore no
redundancy.

My main uncertainty about this is that I'm fairly sure converting
from RAID-1 to RAID-0 leaves you with a RAID-0 of one device and one
marked as spare, then I'm not sure if it does support going to
RAID-10 from that. Should be easy to prove with a test on small
loopback files as block devices though.

Another way it can be done now that we know all the devices are the
same size is to:

1. create a new RAID-10 array that is missing two members.

2. Bring it online, put a filesystem (or LVM) on it,

3. copy data over to it,

4. boot from it making sure that everything works,

5. nuke the old array, add its members to the new RAID-10 thus
making it fully redundant again.

again, for the time period where the second RAID-10 has two members
missing it has no redundancy at all.

If you are very very sure about what you are doing you can do all
that online and only boot into it later but personally I would want
to be satisfied that it booted properly using only the new RAID-10
alone.

This approach is detailed here:

https://superuser.com/a/726063/100242

> >https://blog.voina.org/convert-an-existing-2-disk-raid-1-to-a-4-disk-raid-10/
> >
> >(though that has LVM on top, shouldn't make a difference in these
> >circumstances,
> 
> You've put your finger on why it won't work in this case.  The presence of
> an existing LVM setup on top of the existing RAID1 is what is used to
> migrate the data over.

Yes, that example uses LVM and is therefore not applicable here.

I think it can be done only with mdadm though.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

-- 
GLLUG mailing list
GLLUG@mailman.lug.org.uk
https://mailman.lug.org.uk/mailman/listinfo/gllug

Re: [GLLUG] Link two RAIDs in one LVM?

2020-05-10 Thread Andy Smith via GLLUG
Hello,

On Sun, May 10, 2020 at 10:03:32PM +0200, Dr. Axel Stammler via GLLUG wrote:
> On Sun 2020-05-10 08.53.16, James Courtier-Dutton wrote:
> >So, I think moving to an "LVM mirror" solution is your best bet for
> >future extensibility.
> 
> After reviewing all options, this indeed seems to be the best one in my case.

But it still doesn't let you move filesystems that aren't on LVM
in to LVM. I don't understand why you keep thinking that LVM lets
you do this. My very first reply to you pointed out this would be an
issue for you!

Personally I do not like to do redundancy at the LVM level. The main
reason I use RAID is to avoid the system becoming unavailable (not
booting fully) when a storage device dies. It used to be the case
that an LVM Volume Group would not activate if any PVs were missing,
so if a device failed and you rebooted the system wouldn't come up
without manual intervention. They did fix that after a few years
(initramfs is now willing to activate degraded VGs):

https://bugzilla.redhat.com/show_bug.cgi?id=1337220

So I guess my main problem with it is no longer relevant, but still,
I just prefer redundancy being provided by mdadm.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

-- 
GLLUG mailing list
GLLUG@mailman.lug.org.uk
https://mailman.lug.org.uk/mailman/listinfo/gllug

Re: [GLLUG] Link two RAIDs in one LVM?

2020-05-09 Thread Andy Smith via GLLUG
On Sat, May 09, 2020 at 11:24:15AM +, Andy Smith via GLLUG wrote:
> How do you intend to combine them? You won't be able to put your
> existing array into the LVM without destroying its contents.

Forgot to mention; this sort of conundrum is why it's often useful
to put things in LVM to begin with even when you see no immediate
need.

If your current array already uses LVM then it's trivial to add a
new PV to that.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

-- 
GLLUG mailing list
GLLUG@mailman.lug.org.uk
https://mailman.lug.org.uk/mailman/listinfo/gllug

Re: [GLLUG] Link two RAIDs in one LVM?

2020-05-09 Thread Andy Smith via GLLUG
Hi Axel,

On Sat, May 09, 2020 at 01:03:37PM +0200, Dr. Axel Stammler via GLLUG wrote:
> My original (2016) setup included two hard disk drives of not 4 TB
> but 8 TB capacity in a RAID-1 that has reached 92 per cent
> capacity.

[…]

> I have ordered two more […] my first idea was to create a new
> RAID-1 and to combine the two resulting systems via Logical Volume
> Management. What do you think?

How do you intend to combine them? You won't be able to put your
existing array into the LVM without destroying its contents.

You could do a thing where you:

1) set up the new array as the boot device

2) copy OS and data over to it from the original array

3) boot into this and confirm everything works, if necessary
   physically removing the old array to be sure that everything
   works and all your data is there

4) Nuke the old array, recreate it and add it to your LVM. You now
   have one big LVM.

Downside of this is that because only two devices existed at first,
all your data is still on two devices. The other two are largely
empty, so performance-wise all reads will come from only two of your
four devices. As you (re)write things over time they will spread out
if you have set your LVM allocation method to stripe.

If you have good backups then you could of course nuke everything
and put it back straight onto your LVM of 2x RAID-1.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Please consider the environment before reading this e-mail.
 — John Levine

-- 
GLLUG mailing list
GLLUG@mailman.lug.org.uk
https://mailman.lug.org.uk/mailman/listinfo/gllug

Re: [GLLUG] Link two RAIDs in one LVM?

2020-04-28 Thread Andy Smith via GLLUG
Hi,

On Tue, Apr 28, 2020 at 01:18:08PM +0200, Dr. Axel Stammler via GLLUG wrote:
> I have a 4 TB RAID system (two identical hard disks combined in a
> RAID-1, created using mdadm). Now, after a few years, this has
> reached 90% capacity, and I am thinking about first adding another
> similar 8 TB RAID system and then combining them into one 12 GB
> RAID 1+0 filesystem.

> Which hardware parameters should I look at?

You already received tips to avoid SMR. This cannot be stressed
enough. Worse still, Seagate and WD are selling SMR drives without
marking them as such.

https://www.ixsystems.com/community/resources/list-of-known-smr-drives.141/
https://rml527.blogspot.com/2010/09/hdd-platter-database-seagate-25.html

Do not try to use an SMR drive in a RAID array of any kind.

Next up, if your drives don't support SCTERC timeout facility then
this is not ideal for a Linux RAID system but can be worked around
(and should be). Here is an article I wrote many years ago about
this but it is still the case.


http://strugglers.net/~andy/blog/2015/11/09/linux-software-raid-and-drive-timeouts/

On the linux-raid list many of the requests for help from people
whose arrays won't automatically assemble after a failure are
because their drives don't support SCTERC and they didn't work
around it.

> Which method should I use to combine both RAID systems into one?
> 
> - linear RAID

Doable but not great because:

- Complexity of having arrays be part of an array, e.g. you'll have
  md0 and md1 be your two RAID-1s then md2 will be a linear of
  those.

- Not ideal performance since all IO will go to one pair and
  then once capacity is reached all IO will go other.

- Not sure if you can continue to grow this one later by adding more
  devices.

> - RAID-0

Doable but not great because:

- Complexity of having arrays be part of an array.

- Uneven performance because one "half" is actually twice the size
  of the other "half".

- Cannot grow this setup when you add more drives without rebuilding
  it all again.

If all your devices were the same size there would also be the
option of reshaping RAID-1 to RAID-10, which is possible with recent
mdadm. It turns the RAID-1 into a RAID-0 and then turns that into a
single RAID-10. No further grows/reshapes would be possible after that
though.

> - Large Volume Management (using pvcreate, vgcreate, lvcreate)

(LVM stands for Logical Volume Manager btw 😀)

For ease I most likely would go this way.

You'd make your existing md device be one Physical Volume, make the
new md device be another PV, then make a Volume Group that is both
of those PVs with an allocation mode of stripe.

Pros:

- Can keep adding RAID-1 pairs like this as PVs forever without
  having to move your data about again.

- Pretty simple to manage and understand what is going on.

Cons:

- Will still be a bit uneven performance since the smaller half will
  fill up first and then LVM will only allocate from the larger PV.

- If you've never used LVM before then it's a whole set of new
  concepts.

In all of the above options though, you are going to have to destroy
your filesystem(s) that are on the RAID-1 and put them back onto
whatever system you come up with.

If you're starting over you could consider ZFS-on-Linux.

I've been burnt by btrfs and still see showstopping data loss and
availability problems on the btrfs list on a weekly basis so would
not recommend it at this time. There is likely to be someone who will
say they have been using it for years without issue; if you aren't
convinced then subscribe to linux-btrfs for a month and see what
other people are still dealing with!

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

-- 
GLLUG mailing list
GLLUG@mailman.lug.org.uk
https://mailman.lug.org.uk/mailman/listinfo/gllug

Re: [GLLUG] Multiple grub installs in xen guest

2019-10-11 Thread Andy Smith via GLLUG
Hello,

On Fri, Oct 11, 2019 at 06:21:43PM +0100, Tim Woodall via GLLUG wrote:
> On Fri, 11 Oct 2019, Tim Woodall via GLLUG wrote:
> The debian bootloader does the standard look for pvgrub in /boot/xen,
> then /xen, and then fall back to /boot/grub/grub.cfg and then
> /grub/grub.cfg using the search command.

Yeah I have mine set to look for pvgrub and then grub.cfg and then
menu.lst and then grub.conf, in /boot and / of every block device,
but it would start at the first block device and stop as soon as it
found a match, so I think it would do the same.

There is probably a way to find all matches and present a menu,
instead of stopping at the first one. All the memdisk is doing is
building a grub config that chains to another grub binary or loads
another valid grub config.

Could maybe ask on the grub mailing list?

I think it still would involve building a new grub binary though.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

-- 
GLLUG mailing list
GLLUG@mailman.lug.org.uk
https://mailman.lug.org.uk/mailman/listinfo/gllug

Re: [GLLUG] Server in London

2019-10-11 Thread Andy Smith via GLLUG
On Fri, Oct 11, 2019 at 08:54:29AM +, Andy Smith via GLLUG wrote:
> Here is an example of doing it with the virtualisation stack called
> KVM (not the remote access kind of KVM you mentioned):
> 
> 
> https://blog.appsecco.com/breaking-full-disk-encryption-from-a-memory-dump-5a868c4fc81e

Apologies, that example was with VirtualBox. I just did a quick
search; the previous one I read was for KVM and so I thought that
was it. The virt stack doesn't really matter though; in all cases
the bare metal host can read guest memory.

There are some CPU features coming which can encrypt memory though.
I am not aware of these being deployed in any public provider yet.

Cheers,
Andy

-- 
GLLUG mailing list
GLLUG@mailman.lug.org.uk
https://mailman.lug.org.uk/mailman/listinfo/gllug

Re: [GLLUG] Server in London

2019-10-11 Thread Andy Smith via GLLUG
Hi Marco,

On Fri, Oct 11, 2019 at 09:46:13AM +0100, Marco van Beek via GLLUG wrote:
> On some VM offerings you get a remote KVM, which would allow you to get
> "physical" console access, and then you could encrypt the whole OS and use
> the KVM to enter the key on reboot. That should prevent anyone in the data
> centre from using the disk image without your key.

I don't think you read the entirety of the email you replied to,
which is possibly not surprising as it was large.

The hosting company can read guest memory to obtain the LUKS key.
Here is an example of doing it with the virtualisation stack called
KVM (not the remote access kind of KVM you mentioned):


https://blog.appsecco.com/breaking-full-disk-encryption-from-a-memory-dump-5a868c4fc81e

Disk encryption will not stop an attacker who has a dump of both
your memory and your block device. It will however exclude most
attackers, and even state attackers can be put off by the extra
hassle.

For example, as I mentioned, the UK security services have asked me
for disk snapshots of customers but even me saying I required a
court order made them go away in 100% of cases. For them to proceed
to ask me for a memory dump as well, so that they could try to sift
through it and find the LUKS keys, would presumably require the
customer to be of very great interest to them.

A bored and unethical hosting company employee may be more willing
to expend effort. Either way, it's clearly possible.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

-- 
GLLUG mailing list
GLLUG@mailman.lug.org.uk
https://mailman.lug.org.uk/mailman/listinfo/gllug

Re: [GLLUG] Server in London

2019-10-11 Thread Andy Smith via GLLUG
Hi Axel,

I run a hosting company that has already been mentioned in this
thread, so there may be bias, but I will try to be objective.

The main issues with colocation in your situation are:

- It's overkill for your needs. You can't easily rent less than 1
  rack unit (https://en.wikipedia.org/wiki/Rack_unit) but the amount
  of compute that you can fit into 1RU is immensely more than what
  you need based on your comments here. That makes it a waste of
  money and power.

- It leaves you with some hardware whose life cycle you need to
  manage. That is, it can break, it will become obsolete after less
  than 10 years, so you've got to replace it or bits of it, which
  needs human interaction, which is expensive.

- Maybe the physical management of pieces of computer hardware at a
  distance is a new skill you'll need to learn, which possibly won't
  be that useful for any other area of your life.

You say that you need the hardware to be in London, but almost
anywhere in Western Europe is only a few ms away from London, and
even East coast USA is only 60–70ms (round trip time).

I love London, I live in London, I run a hosting company based in
London, but London is not necessarily always the best place to host
servers in. It's expensive compared to a lot of other places, and
Brexit may leave you in a difficult position with regard to the
storage of personal data.

So, first of all I would never recommend colo for your uses. You are
too small a player for it to make sense. You should only do it if
you need absolute control over the specification and ownership of
the hardware, and possibly if you have some security objections to
the other options.

Renting the hardware from the hosting company will be a lot cheaper,
gets around several of the issues above, and may be viable for what
you want. This is called a "dedicated server". You could rent one in
Germany from the likes of Hetzner, and that would be astoundingly
cheap, and I expect it would work fine for you from anywhere in
Western Europe. Hetzner has a bit of a spam problem so if you intend
to send email to third parties then you may wish to rethink that
one due to aggressive blocking.

It may be tempting to go even cheaper and rent from the likes of OVH
(probably have a location in London, certainly multiple in Europe).
Unfortunately OVH have a huge spam problem that they don't appear to
be bothered about, so this is anti-recommendation for OVH for any
purpose, for this reason. If you don't care that they deliberately
choose to not tackle their spammer problem, and you yourself don't
need to send email, they will probably work out just fine for you.

I know that Mythic Beasts is a good quality hosting company based in
Cambridge but hosting out of London for a good while now. They'll
sell you colo or dedicated servers or virtual servers but it won't
be bargain basement.

Virtual servers could be just what you need. You get full control of
your OS, but you're sharing hardware and the hardware is someone
else's problem.

Good London-based virtual server providers include Mythic Beasts and
Portfast. I'd have previously included Bytemark, but they were
recently sold to iomart group. I have no personal experience of any
of those, that's just what I've heard from others.

Linode is a really big name in virtual servers and they have a
datacentre in London. If they do what you want then they are a
decent offering, but you will be one customer amongst millions so
the customer service can sometimes be lacking. That is from personal
experience as despite them being a competitor to me, I do use Linode
for some out-of-UK things.

Digital Ocean is also a big name in virtual servers and likewise
have a London datacentre, I also have to give an anti-recommendation
here though, as they too have a huge spammer problem that they have
no interest in resolving.

You hint at not wanting to go the virtual server route because of
concern for the safety of your data. I think that looking at it this
way is a bit of a mistake; the correct response to concern over your
data is to have good backups of your data.

If your data is on a physical machine that you own, it can still be
stolen or destroyed. You can make an error, your software can make
an error, the hosting company can make an error, it can all go up
in flames. The hosting company can go bankrupt and leave you with no
easy physical access to your property. That would get resolved
eventually, but that would be small comfort in the intervening time.

No, even with colo, you need good off-site backups. Treat that as an
absolute requirement and then it influences your other choices.

As far as security goes, there are some weaknesses with dedicated
servers and with virtual servers.

With dedicated servers, since it's not your hardware you don't know
if it has some malicious gadget attached to it that allows someone
to snoop on your data. Of course, technically you don't know if the
hardware you buy off the shelf has that e

Re: [GLLUG] Speculative IPv6 probing

2019-09-25 Thread Andy Smith via GLLUG
On Wed, Sep 25, 2019 at 06:44:35PM +0100, Tim Woodall via GLLUG wrote:
> I'm seeing probes obviously attempting to hunt for machines on IPv6.

[…]

> Is this going to be the state of IPv6 going forwards?

Yes. What you're running on which IPs and ports is valuable
information which is being compiled and sold.

> Anyone else seeing anything like this.

Yes. Also in the last year I've been seeing frequent SSH dictionary
attacks on non-standard (IPv4) ports.

On Wed, Sep 25, 2019 at 06:50:21PM +0100, John Winters via GLLUG wrote:
> I can't help wondering what the objective is.

To compile a database of what is running on what IPs and ports and
sell that to people.

> Scanning the whole of the IPv6 address space is going to take a while, and
> all it's going to tell you is that there is a machine at a particular
> address - just the same as if you did it for IPv4.

It already is being done for IPv4 extensively, and there are
multiple subscription services such as Shodan which sell [searches
on] that database to their users.

So, for example, you find out some Internet of Shit device has an
open telnet on port 54321, you then put that into the Shodan-like
service and it spits back every machine on the Internet with that
port open. You can even give if strings that it should have
responded with, to narrow down the list. Boom, instant botnet.

It used to be extremely frowned-upon to mass-scan the Internet;
abuse reports used to get filed and people used to get told to stop
doing it by their upstream providers. Now they just say they are a
research tool and their money is as green as anyone else's.

Scanning all of IPv6 currently poses a bit more of a challenge, but
heuristics will be used to give it a good try anyway.

> What's there to be gained?

Information that has monetary value.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

-- 
GLLUG mailing list
GLLUG@mailman.lug.org.uk
https://mailman.lug.org.uk/mailman/listinfo/gllug