main

main@lists.alug.org.uk

1 participants
10372 discussions

ePub reader, is there really not one in Ubuntu/Debian?
by Chris Green 27 Jun '20

27 Jun '20

I want to read (well, 'use', it's a programming manual) that's in ePub format. There seems to be no default, or even available, ePub reader in Ubuntu. There are dozens of programs for creating ePub format but nothing for simply reading it. Am I missing something obvious somewhere? -- Chris Green

2 2

Ensuring that a systemd unit starts *before* any networking
by Mark Rogers 25 Jun '20

25 Jun '20

Not sure if there are any systemd experts here, but I'll ask on the off-chance; I've already posted on Stack Overflow [1] if anyone knows the answer and wants credit for answering it there. How do I ensure a systemd unit runs to completion before any network tasks start? It sounds like a simple task but I've been banging my head on this for ages and every time I think it's working it turns out I was just lucky with timing. I have some code which generates dhcpcd.conf and wpa_supplicant.conf from settings in a database so obviously that needs to happen before any of those network tools start. But whatever magic I try in my unit configuration seems to have no impact on the start order of the unit. My current attempt is: [Unit] Description=Config generation from DB Before=networking.service [Service] Type=oneshot ExecStart=/home/mark/bin/db2config.py [Install] RequiredBy=network.target Any ideas? [1] https://stackoverflow.com/questions/62574482/ensuring-that-a-systemd-unit-s… -- Mark Rogers // More Solutions Ltd (Peterborough Office) // 0844 251 1450 Registered in England (0456 0902) 21 Drakes Mews, Milton Keynes, MK8 0ER

1 0

Mint mirrors
by Bev Nicolson 14 Jun '20

14 Jun '20

Anyone else having issues refreshing the mirrors? (WiFi is fine generally so I don't think it's problem at my end.) This isn't a one-off. I get this message: <<Failed to fetch http://www.mirrorservice.org/sites/packages.linuxmint.com/packages/dists/te… 503 Service Unavailable [IP: 91.230.243.15 80]Some index files failed to download. They have been ignored, or old ones used instead.>> Bev

2 2

dhcpcd fallback
by Mark Rogers 04 Jun '20

04 Jun '20

I have the following in /etc/dhcpcd.conf (on a Pi), which (as I understand it) should seek an IP via DHCP but fallback to 192.168.60.100 if none is offered. My problem is that more often than not I end up with the fallback IP address rather than one from DHCP, despite the Pi being on a network with a DHCP server. (The connection to DHCP is a bit convoluted: Pi cabled to Wifi access point, which is on my home wifi network, which gives it access to my home router's DHCP server.) Any suggestions how I can diagnose this? I'm not sure if the complex connection to DHCP is the issue or not (and it does sometimes work so I don't think it's a config issue) but I'm not sure where to start looking and I'd like this to work over unreliable links if possible. If I comment out the fallback line I get a reliable DHCP address. # fallback to static profile on eth0 profile static_eth0 static ip_address=192.168.60.100/24 static routers=192.168.60.250 static domain_name_servers=192.168.60.250 interface eth0 fallback static_eth0 -- Mark Rogers // More Solutions Ltd (Peterborough Office) // 0844 251 1450 Registered in England (0456 0902) 21 Drakes Mews, Milton Keynes, MK8 0ER

1 2

2600 meeting at 18:00 on Friday the 5th June.
by Viperfang 02 Jun '20

02 Jun '20

Quick heads up about this months Norwich 2600 meeting, more info at http://www.norwich2600.co.uk

1 0

Updating Ubuntu from 16.04 to 18.04 (xenial to bionic)
by Christopher Dawkins 01 Jun '20

01 Jun '20

I tried this first a year or two ago and came across the same problem - a problem with the rfkill package, one for which I have no use anyway. Last Friday I had three desktop Ubuntu 16.04 systems, set up at three different times. On Saturday one updated smoothly to 18.04 using the proper 'sudo do-release-upgrade' method. Both the others failed with the nasty 'Hash Sum mismatch' error on rfkill. As one did last year, when I learnt that it was a repository sync problem that would clear up later. I have googled widely and implemented (I think) every solution. I have cleaned, updated, upgraded, done dist-upgrade, autoremoved, wiped /var/lib/apt/lists and /var/cache/apt/archives, and made sure both Acquire-by-hash and Acquire::CompressionTypes::Order::=gz are operating. I have downloaded (with wget) both the 4945 bytes of the xenial version and the 5005 bytes of the bionic version and installed them at separate times in /var/cache/apt/archives before trying the update again. Every time, it barfs on rfkill with a 'Hash Sum mismatch'. I find in my notes three other reported sizes for rfkill: 5045, 8530, 8580 and 8612 bytes. Since I don't need rfkill, can anyone suggest any way to get over this? Maybe the problem is that I purged it half way through a long weekend of wrestling. It refuses to reinstall with the following message. ==================================================================================== Need to get 8,530 B of archives. After this operation, 33.8 kB of additional disk space will be used. Get:1 http://gb.archive.ubuntu.com/ubuntu xenial-updates/main amd64 rfkill amd64 0.5-1ubuntu3.1 [8,530 B] Err:1 http://gb.archive.ubuntu.com/ubuntu xenial-updates/main amd64 rfkill amd64 0.5-1ubuntu3.1 Hash Sum mismatch Fetched 4,945 B in 0s (238 kB/s) E: Failed to fetch http://gb.archive.ubuntu.com/ubuntu/pool/main/r/rfkill/rfkill_0.5-1ubuntu3.… Hash Sum mismatch E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing? =================================================================================== and I note that it fetched only around half of what it needed, but it seems to always do this. When I try again with apt --fix-missing install rfkill I get the same with a final error: E: Internal Error, ordering was unable to handle the media swap The usual error message involves two GETs: ==================================================================================== Get:1 http://gb.archive.ubuntu.com/ubuntu bionic-updates/main amd64 rfkill amd64 2.31.1-0.4ubuntu3.6 [24.8 kB] Err http://gb.archive.ubuntu.com/ubuntu bionic-updates/main amd64 rfkill amd64 2.31.1-0.4ubuntu3.6 Hash Sum mismatch Fetched 4,945 B in 0s (0 B/s) Get:1 http://gb.archive.ubuntu.com/ubuntu bionic-updates/main amd64 rfkill amd64 2.31.1-0.4ubuntu3.6 [24.8 kB] Err http://gb.archive.ubuntu.com/ubuntu bionic-updates/main amd64 rfkill amd64 2.31.1-0.4ubuntu3.6 Hash Sum mismatch Fetched 5,005 B in 0s (0 B/s) Could not download the upgrades ====================================================================================== though at times there is a second occurrence of the second four-line message. -- Christopher Dawkins Garnetts Corner, Jollyboys Lane North, Felsted, Dunmow, Essex CM6 3DU 07816 821659

1 0

ALUG] Peculiar DNS clash on Ubuntu 18
by Al 24 May '20

24 May '20

This is what I did: :~$ cat /etc/resolv.conf # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 9.9.9.9 nameserver 9.9.9.9 nameserver 127.0.0.53 search lan :~$ sudo systemctl disable systemd-resolved [sudo] password for xxxx: Removed /etc/systemd/system/multi-user.target.wants/systemd-resolved.service. :~$ Al On Sun, 24 May 2020 12:00:01 +0100 main-request(a)lists.alug.org.uk wrote: > Send main mailing list submissions to > main(a)lists.alug.org.uk > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.alug.org.uk/mailman/listinfo/main > or, via email, send a message with subject or body 'help' to > main-request(a)lists.alug.org.uk > > You can reach the person managing the list at > main-owner(a)lists.alug.org.uk > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of main digest..."

2 1

odd DNS lookup results
by mick 23 May '20

23 May '20

Hi Guys This may be deemed off topic because it is not strictly directly Linux related, although all the machines involved are running Linux. However, there are some networking experts here and I would welcome a view on something that is driving me nuts. The background is that I am experimenting with moving all my DNS lookups to DNS over TLS (to preserve privacy). I run local dnsmasq caching resolvers on two of my internal networks and for a while now I have forwarded upstream DNS requests to one of four unbound resolvers running on my OpenVPN end points. (So if I use the VPN on the machine called tap, I forward requests to unbound on tap). Because any observer between my VPN endpoint and the root, TLD or other domain DNS servers can see my requests I want now to encrypt all requests leaving my networks. I /could/ retain my unbound resolvers with suitable configuration changes so that they accept DoT requests from my local nets and then in turn forward upstream using DoT, but there are a limited number of servers accepting DoT requests in the wider world. So if I retain unbound, I would end up forwarding my upstream requests over DoT to third party resolvers such as Google, Quad9 or Cloudflare. I see no point in doing that when I can (and indeed have) install stubby on my local DNS resolvers and simply pass requests from dnsmasq through stubby to a public resolver (or actually a round robin list). Because I really don't want to pass my DNS requests to a large resolver which then logs them (as does Google) or both logs and interferes with them (as do cleanbrowsing, OpenDNS or Quad9) I have been testing outside DNS resolvers using a shell script tool called dnsperftest I found here[1]. I modified that script to add some additional resolvers taken from the defaults provided in stubby's configuration plus some others taken from privacytools.io [2] and dnsprivacy [3]. I also added some other domains to the test set so that I had 20 domains to test across some 18 public resolvers. Some of those resolvers (such as google 8.8.8.8 and Quad9 at 9.9.9.9) I will not actually use in real life, but they are big anycast systems and I wanted a benchmark for my likely slower choices which are privacy conscious. I then ran the test script from my desktop using an untampered connection through my ISP, followed by connections through each of my four VPN endpoints. As expected, I got faster lookups without the VPNs than with. I then ran the same tests from the machines I use as VPN endpoints. And again, as expected, and because those VMS are in large datacentres dotted around europe, I got much faster lookups from there. Herein lies the interesting bit. The bit I really don't understand. Take a look at the results (averages only) in the attached text file. You will see there that on all the tests run from my desktop either straight through my ISP or through my VPNs, cloudflare's anycast servers on 1.1.1.1 and 1.0.0.1 come out fastest, But, and this is the bonkers bit, if I run the same test directly on the VPN end points, 1.1.1.1 is slowest (and in fact I cannot ping 1.1.1.1 from any of my VPN enpoints but I can when I run the connection through a VPN to that same endpoint.) This bothers the hell out of me because it should make no difference whether I try to reach 1.1.1.1 through my VPN or direct from the machine which constitutes the endpoint of that VPN /UNLESS/ my traffic is taking a route I do not understand. If that is the case, then my protective security stance has a major problem. So: does anyone out there have any idea what is going on? (Oh, and I know that cloudflare got the 1.1.1.1 address from APNIC, and I also know that 1.1.1.1 has been used as a "test" address in a lot of places in the past and that can cause some routing oddities, but if that were the problem then I would see the same difficulty from my desktop through the VPN as I see at the VPN endpoint. Wouldn't I?) Thanks in advance Mick [1] https://github.com/cleanbrowsing/dnsperftest [2] https://www.privacytools.io/providers/dns/#icanndns [3] https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Public+Resolvers --------------------------------------------------------------------- Mick Morgan gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312 https://baldric.net/about-trivia ---------------------------------------------------------------------

2 3

Peculiar DNS clash on Ubuntu 18
by Jenny Hopkins 23 May '20

23 May '20

Hello, I have a computer running Ubuntu 18.4 with MATE desktop. With no apparent reason (no changes to either PC or DHCP server) the PC lost its DNS entries a few days ago, and seemed to be querying itself using IP 127.0.0.53 (or was it 153?). I used systemd-resolve to re-add the missing entries, and this worked, however the next day they had gone again. I then used the GUI provided by mate system-administration-network, and this worked (seems to run some perl scripts in /usr/share/system-tools-backends) but again, next day they had vanished and only the 127.0.0.53 appeared in the GUI. Has anyone any clue of what could be running overnight to overwrite the DNS entries? I can't even find where my hand-entered entries are ending up. Thanks, Jenny

1 0

Alternatives to TsoHost?
by Chris Green 13 May '20

13 May '20

I have been using TsoHost as my main web hosting provider for almost ten years, until recently they have been very good. However over the past few weeks when I have contacted their support they really haven't been anywhere near as quick as they used to be, nor have they been particularly good at answering my questins. My sites all work OK still, no issues there, and support have eventually come up with answers but it's just nowhere near as good as it used to be. There's no auto-acknowledgement of E-Mail/posted support questions and even though they say they've moved a lot of technicians to Live Chat it's more often then not unavailable (not that I like Live Chat for technical support really). So has anyone else here who uses TsoHost noticed the deterioration? ... and maybe more to the point any suggestions for alternatives? I have around ten hosted web sites with very low traffic at the moment and that's unlikely to change. The one significant requirement other than the obvious sort of stuff is ssh access so I can use the site as a bridge/buffer for outside connections to home. -- Chris Green

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

main