Re: [GLLUG] Booting biosboot
On Mon, 7 Mar 2022, Henrik Morsing via GLLUG wrote: Good morning, I have installed CentOS on the latter half of a disk in an old lpatop, where the first half conatins Ubuntu. The CentOS install, after booting, did not appear to have altered or re-installed a boot loader. I've read the CentOS manual, which just says you need a biosboot partition on BIOS/GPT disks (same does the installer, if you try to remove it), the GRUB documentation, which describes you need it, and various online blog that generously describe how to create it. Not one bit of information described what to do to GRUB to boot it. I've tried adding a manual grub.cfg entry to point to gpt#, # being both the biosboot partition and the root partition, but nether worked. What is the solution here? And is the CentOS installer broken? Do you mean a partition table that looks something like this? root@xen17:~# fdisk -l /dev/sda Disk /dev/sda: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors Disk model: Samsung SSD 870 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: DAD8D524-D8F7-D04D-A21E-C8E14F39285B Device StartEndSectors Size Type /dev/sda12048 4095 2048 1M BIOS boot /dev/sda24096 264191 260096 127M EFI System /dev/sda3 264192 1953525134 1953260943 931.4G Linux filesystem Then you don't always need the bios boot partition. root@dirac:~# fdisk -l /dev/nvme0n1 Disk /dev/nvme0n1: 119.2 GiB, 128035676160 bytes, 250069680 sectors Disk model: LITEON CA1-8D128 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: A9C70A11-3BDB-4338-ACB2-DAB386027BAC Device Start End Sectors Size Type /dev/nvme0n1p1 34264191264158 129M EFI System /dev/nvme0n1p3 264192 250069646 249805455 119.1G Linux filesystem IIRC you only need a bios boot to use legacy boot. If you're exclusively EFI (dirac doesn't support anything else) then the bios boot partition won't be used. IIUC the problem is that grub needs some disk space for legacy boot and the GPT format doesn't have enough unused space for grub to sneek in so it needs an explicit partition reserved for it. Tim. -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
Re: [GLLUG] basic IPv6 questions
On Mon, 4 Oct 2021, Andy Smith via GLLUG wrote: 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. is there any advantage to doing this over running radvdump? If you change radvd to transmit frequently (say every 10s) for debugging purposes and you include DNS entries in the broadcasts and you have redundant servers broadcasting then you might have performance issues on the machines consuming the packets and rewriting resolv.conf. (it took me a long time to track that one down as the problems were intermittent...) -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
Re: [GLLUG] IPv6 addresses
On Mon, 19 Jul 2021, John Winters via GLLUG wrote: On 19/07/2021 11:25, Tim Woodall via GLLUG wrote: On Sun, 18 Jul 2021, 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. [snip] I'm not completely sure how you have static /48 but dynamic /64. Can you not assign yourself a fixed /64 from the /48 if that's what you want? Presumably the sister is getting allocated a /64 which varies, but always comes from the same /48. Ah, yes. I misread the OP. https://community.bt.com/t5/Archive-Staging/IPV6-Settings/td-p/1699523 and https://www.ispreview.co.uk/index.php/2016/11/bt-broadband-lines-now-support-ipv6-internet-addresses.html Seems to suggest that you should get a /56. Does the OP get a /64 from the same /56 each time or is it a different /56 each time? -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
Re: [GLLUG] IPv6 addresses
On Sun, 18 Jul 2021, 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. I'm not completely sure how you have static /48 but dynamic /64. Can you not assign yourself a fixed /64 from the /48 if that's what you want? If you're going to be publishing the /64 in DNS somewhere then <48-prefix>:::/64 would probably make sense. If you're not then some random 16 bits might make more sense. Tim. -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
Re: [GLLUG] Power control over IP
On Tue, 1 Jun 2021, Marco van Beek via GLLUG wrote: As many others have already said. the ideal is if this is part of the baseboard management tool of the servers. Although both DELL and HP call it by their own names (and often charge extra for additional features) the generic term is IPMI, or Intelligent Platform Management Interface (https://en.wikipedia.org/wiki/Intelligent_Platform_Management_Interface). However, you do have to buy servers that support this, but it gives you a lot of control, and is a lot cheaper that a compilation of a networked KVM and a networked PDU. In most cases it is brought out as a separate Ethernet port on the back of the server, which means you can run it on a completely separate network should you wish for security purposes. I've been working on a rpi 4 version of this. The pi4 supports gadget mode and host mode simultaneously so I have a HDMI framegrabber (and VGA->HDMI for the machines that don't support HDMI) along with a 4 way HDMI kvm switch to allow me to control four machines from a single RPI (for circa 100GBP). There are other solutions on the web but all of them use the standard USB keyboard gadget that doesn't work with every bios that I have so I've had to build my own. Let me know if you're interested but it's not quite "production ready" yet - the electronics to control the power and reset switches and monitor the power and HDD led are on a breadboard at the moment... Tim. -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
[GLLUG] empty cd cases.
Hi all, I'm doing a clearout and I have around 35 empty (single) CD cases. These are going free if anyone wants them (collect from central London) otherwise they're going into the recycling. Additionally I have found 4 x DVD+RW 5 x DVD+R 12 x Business card CD-R 1 x CD-RW 1 x CD-R These are of unknown age, most still have their shrink-wrap. But based on the two that had data on them they're 17 years old or more! IIRC the business card CD-R weren't very easy to record successfully even when new. Finally, I have Stroustrup the C++ programming language second edition. None of this is worth the cost of postage (IMO) but if anyone has a use for some or all of this (perhaps melting down for 3d printing!) then shout and I'll hang on to them until they can be collected. Tim. -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
Re: [GLLUG] ssh local port forwarding remote interface binding.
On Thu, 14 Jan 2021, damion.ya...@gmail.com wrote: On Thu, 14 Jan 2021, Tim Woodall via GLLUG wrote: In ssh -N -L 8080:webserver:80 gateway Is there any way to specify which interface should be bound on gateway other than by changing the routing table on gateway? I found https://unix.stackexchange.com/questions/16057/use-ssh-with-a-specific-network-interface And my ssh manpage has indeed got a -b to change the bind address on your initial outgoing connection and also -B to change bind interface. The rest about binding for the listening onb a fwd is indeed not helping your cause. I'll give it a try but I assumed that was controlling the interface used on the local machine, i.e. the connection to gateway rather than the one from it. Tim. -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
Re: [GLLUG] ssh local port forwarding remote interface binding.
Sent this from the wrong email address and I guess it got filtered out. Apologies if it's a duplicate. On Thu, 14 Jan 2021, James Courtier-Dutton wrote: On Thu, 14 Jan 2021 at 07:30, Tim Woodall via GLLUG wrote: Hi all, In ssh -N -L 8080:webserver:80 gateway Is there any way to specify which interface should be bound on gateway other than by changing the routing table on gateway? Google isn't helping much as everything is talking about bind address that the forwarded connection _listens_ on and I don't care about that, Hi, Lets have: A = the client PC you are ssh from. B = gateway C = webserver. The above will open a port 8080 on A, listening on 127.0.0.1 When you connect to port 8080 on A, the session is tunnelled through the ssh port 22 session. B then opens a tcp session from B:anyport -> C:80 Does this help answer your question? Unfortuantely not, here's the problem: tim@B $ telnet C 80 Trying C... Connection timed out telnet: connect to address C: Connection timed out tim@B $ telnet -b bind_ip1 C 80 Trying C... Connected to C. Escape character is '^]' tim@B $ telnet -b bind_ip2 C 80 Trying C... Connected to C. Escape character is '^]' I can change the routing table so that a working interface is chosen except that I actually have multiple possible routes so I want to be able to chose the interface at the point of setting up the forwarding depending on which core ssh will be bound to. Part of the reason for requiring the interface to be chosen is to avoid mindlessly depending on the one configured in the kernel rather than thinking about which interface to use. I cannot see any way to specify bind_ip to ssh. Everything I can find talks about -L :8080:C:80 - but that's not my problem, it's the binding on the B->C hop that I need to configure. At the moment I'm running a socat on B. So I have (approx) ssh -L 8080:localhost:8080 'socat TCP-LISTEN:8080 TCP:C:80,bind=bind_ip1' B but apart from running an extra process on B, I need to pick an unused port for the localhost hop - so I cannot run an identical command from two different source machines. I'm hoping there's some magic I can put in .ssh/config (on either/both of A and B) to make this work without the socat (or a commandline option although I've pored though the man page and I don't think there's anything.) Tim. -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
[GLLUG] ssh local port forwarding remote interface binding.
Hi all, In ssh -N -L 8080:webserver:80 gateway Is there any way to specify which interface should be bound on gateway other than by changing the routing table on gateway? Google isn't helping much as everything is talking about bind address that the forwarded connection _listens_ on and I don't care about that, Tim. -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
[GLLUG] Failing DNS queries
I'm getting a lot of dns queries that are (correctly) being refused. 2 73.74.74.8 (.): view external: query failed (REFUSED) for ./IN/ANY at ../../../bin/named/query.c:7144 3 24.51.114.75 (.): view external: query failed (REFUSED) for ./IN/ANY at ../../../bin/named/query.c:7144 5 75.74.75.75 (.): view external: query failed (REFUSED) for ./IN/ANY at ../../../bin/named/query.c:7144 20 47.33.153.17 (.): view external: query failed (REFUSED) for ./IN/ANY at ../../../bin/named/query.c:7144 22 98.255.163.109 (.): view external: query failed (REFUSED) for ./IN/ANY at ../../../bin/named/query.c:7144 25 162.144.50.35 (.): view external: query failed (REFUSED) for ./IN/ANY at ../../../bin/named/query.c:7144 28 100.16.208.90 (.): view external: query failed (REFUSED) for ./IN/ANY at ../../../bin/named/query.c:7144 31 3.239.138.250 (.): view external: query failed (REFUSED) for ./IN/ANY at ../../../bin/named/query.c:7144 38 74.74.74.9 (.): view external: query failed (REFUSED) for ./IN/ANY at ../../../bin/named/query.c:7144 69 185.236.201.140 (.): view external: query failed (REFUSED) for ./IN/ANY at ../../../bin/named/query.c:7144 80 67.186.81.99 (.): view external: query failed (REFUSED) for ./IN/ANY at ../../../bin/named/query.c:7144 82 138.128.138.146 (.): view external: query failed (REFUSED) for ./IN/ANY at ../../../bin/named/query.c:7144 86 108.49.177.17 (.): view external: query failed (REFUSED) for ./IN/ANY at ../../../bin/named/query.c:7144 112 173.24.45.165 (.): view external: query failed (REFUSED) for ./IN/ANY at ../../../bin/named/query.c:7144 121 3.138.246.95 (.): view external: query failed (REFUSED) for ./IN/ANY at ../../../bin/named/query.c:7144 133 78.2.12.185 (.): view external: query failed (REFUSED) for ./IN/ANY at ../../../bin/named/query.c:7144 148 31.215.87.14 (.): view external: query failed (REFUSED) for ./IN/ANY at ../../../bin/named/query.c:7144 153 75.181.6.66 (.): view external: query failed (REFUSED) for ./IN/ANY at ../../../bin/named/query.c:7144 208 184.51.146.184 (.): view external: query failed (REFUSED) for ./IN/ANY at ../../../bin/named/query.c:7144 236 104.238.163.81 (.): view external: query failed (REFUSED) for ./IN/ANY at ../../../bin/named/query.c:7144 286 154.3.250.71 (.): view external: query failed (REFUSED) for ./IN/ANY at ../../../bin/named/query.c:7144 359 173.231.186.139 (.): view external: query failed (REFUSED) for ./IN/ANY at ../../../bin/named/query.c:7144 Thats in the first half hour of today. It's not really causing me a problem (so far) - although I might look at ratelimiting the queries to a few a day at the firewall. But is this some sort of DNS amplification that I've not heard of and do I need to do something different? Roughly 5000 queries last week, 1000 the week before, just two the week before that but 140k queries this week like this. This is the secondary server. The primary saw similar ramp up but I've only seen 5000 this week Tim. -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
Re: [GLLUG] read -t 1 hangs on reading from an unconnected pipe.
Hi Fred,
On Thu, 7 Jan 2021, Fred Youhanaie via GLLUG wrote:
Hi Tim
Happy New Year to you too.
This is expected behaviour with pipes. The first process to open the pipe
will block until the other end opens too.
You confirm with the following - the first echo does not happen until the
shell itself has completed the open (
time { echo hello ; read -t 1 ;}
Ah, thanks. This example helped me make sense of what was going on.
You can try something like this and drop it in the background before the read
sleep 999 >/tmp/pipe &
Neat trick. I don't actually need it now I know that the read can block
I've tweaked things so I don't get into this situation but it might be
useful in the future.
Regards,
Tim.
Cheers,
Fred
On 07/01/2021 09:31, Tim Woodall via GLLUG wrote:
Happy new year to all.
I didn't expect this:
tim@einstein(9):~$ mkfifo /tmp/pipe
tim@einstein(9):~$ time read -t 1 /tmp/pipe
I had expected the read to time out after one second.
Is there any way to make read always timeout, even if the other end of
the pipe isn't connected?
Tim.
--
GLLUG mailing list
GLLUG@mailman.lug.org.uk
https://mailman.lug.org.uk/mailman/listinfo/gllug
Re: [GLLUG] growisofs -speed=1
On Tue, 1 Dec 2020, Tim Woodall via GLLUG wrote: I burn backups to blu-ray about once per month. Commandline is: growisofs -dvd-compat -speed=1 -Z /dev/cdrom=$UDFIMAGE Mostly this works fine: I get messages like: 2288910336/24756879360 ( 9.2%) @0.9x, remaining 96:21 RBU 100.0% UBU 96.9% 2302017536/24756879360 ( 9.3%) @0.9x, remaining 96:24 RBU 100.0% UBU 96.9% 2315321344/24756879360 ( 9.4%) @0.9x, remaining 96:16 RBU 100.0% UBU 96.9% 2328100864/24756879360 ( 9.4%) @0.9x, remaining 96:10 RBU 100.0% UBU 96.9% 2340225024/24756879360 ( 9.5%) @0.8x, remaining 96:16 RBU 100.0% UBU 96.9% 2353135616/24756879360 ( 9.5%) @0.9x, remaining 96:09 RBU 100.0% UBU 96.9% ... However, it's started burning at double speed @2.1x sometimes. Sometimes the burn completes like that, but doing an md5sum on the image (which I always do once I've burned the disk) shows that there are definitely some errors although the disk will mount ok. And other times the burn fails part way through. Does anyone know why it's ignoring my -speed=1 setting? From the manpage: Keep in mind that N essentially denotes speed closest to N*1385KBps in DVD or N*4496KBps in Blu-ray Disc case Based on the snippet above - roughly 105 minutes to burn this disk. 24756879360/4496000/0.9 = 101 minutes. So the maths looks correct and I don't know why it's sometimes burning at 2.1x. And as soon as I sent the above the burn actually failed: 9682092032/24756879360 (39.1%) @0.9x, remaining 64:22 RBU 100.0% UBU 96.9% :-( unable to WRITE@LBA=4829a0h: Input/output error :-( write failed: Input/output error /dev/cdrom: flushing cache :-( unable to FLUSH CACHE: Input/output error :-( unable to SYNCHRONOUS FLUSH CACHE: Input/output error That's the first time I've had a 0.9 speed burn fail :-( Tim. -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
[GLLUG] growisofs -speed=1
I burn backups to blu-ray about once per month. Commandline is: growisofs -dvd-compat -speed=1 -Z /dev/cdrom=$UDFIMAGE Mostly this works fine: I get messages like: 2288910336/24756879360 ( 9.2%) @0.9x, remaining 96:21 RBU 100.0% UBU 96.9% 2302017536/24756879360 ( 9.3%) @0.9x, remaining 96:24 RBU 100.0% UBU 96.9% 2315321344/24756879360 ( 9.4%) @0.9x, remaining 96:16 RBU 100.0% UBU 96.9% 2328100864/24756879360 ( 9.4%) @0.9x, remaining 96:10 RBU 100.0% UBU 96.9% 2340225024/24756879360 ( 9.5%) @0.8x, remaining 96:16 RBU 100.0% UBU 96.9% 2353135616/24756879360 ( 9.5%) @0.9x, remaining 96:09 RBU 100.0% UBU 96.9% ... However, it's started burning at double speed @2.1x sometimes. Sometimes the burn completes like that, but doing an md5sum on the image (which I always do once I've burned the disk) shows that there are definitely some errors although the disk will mount ok. And other times the burn fails part way through. Does anyone know why it's ignoring my -speed=1 setting? From the manpage: Keep in mind that N essentially denotes speed closest to N*1385KBps in DVD or N*4496KBps in Blu-ray Disc case Based on the snippet above - roughly 105 minutes to burn this disk. 24756879360/4496000/0.9 = 101 minutes. So the maths looks correct and I don't know why it's sometimes burning at 2.1x. Tim. -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
Re: [GLLUG] IP address problems.
On Thu, 12 Nov 2020, Chris Bell via GLLUG wrote: On Thursday, 12 November 2020 11:49:25 GMT John Winters via GLLUG wrote: On 12/11/2020 11:44, Chris Bell via GLLUG wrote: [ about difficulties configuring persistent IPv6 addresses ] Hi Chris, I've found that I needed to use two different strategies depending on whether the initial address is configured statically or picked up automatically. If you tell me which you're doing I will dig out my notes on the relevant approach. Cheers, John I am trying to get both working, with dedicated RaspberryPi boxes normally sitting in the DMZ but sometimes pre-configured in another network, mainly dedicated boxes in another network, and mainly random boxes used for general web access, etc, in another. I am trying to set up a replacement firewall, but I discovered a few more problems when one of two boxes running Bind9 locally died a few days ago. It seems that some of the RaspberryPi boxes have changed the name of their ethernet interface again, and could no longer find the IPv6 gateway. Adding up ip -6 addr add ... lines to the interface stanza should allow you to add more static IP addresses. I'm not using dhcp6, I use SLAAC but the following might prove useful if you want to go along that route. pre-up echo 64 >/proc/sys/net/ipv6/conf/$IFACE/accept_ra_rt_info_max_plen To allow routes other than the default route to be received. pre-up ip token set ::201/64 dev $IFACE To allow you to use something other than the MAC during config -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
Re: [GLLUG] Retrieving debian source package.
On Sun, 12 Jul 2020, Tim Woodall via GLLUG wrote: I have managed to get it to work but I don't like it: Finally - I've worked out what I was doing wrong. the deb10u2 was coming from security.debian.org but I wasn't getting the sources from the same place. Now it is all working the way I wanted it to with no pin hacks. tim@dirac:~/git/pkgrebuild/squid$ apt-get --print-uris -t buster source squid Reading package lists... Done Selected version '4.6-1+deb10u2' (buster) for squid NOTICE: 'squid' packaging is maintained in the 'Git' version control system at: https://salsa.debian.org/squid-team/squid.git Please use: git clone https://salsa.debian.org/squid-team/squid.git to retrieve the latest (possibly unreleased) updates to the package. Need to get 5,241 kB of source archives. 'http://security.debian.org/pool/updates/main/s/squid/squid_4.6-1+deb10u2.dsc' squid_4.6-1+deb10u2.dsc 2674 SHA256:6642185cf2a43854da25982f7a6a8550439d172dd69183ffc5fccb6538f46641 'http://security.debian.org/pool/updates/main/s/squid/squid_4.6.orig.tar.gz' squid_4.6.orig.tar.gz 5174095 SHA256:190f5c015624f53279e5376749b08192f4023219398db3a40892d484513701c7 'http://security.debian.org/pool/updates/main/s/squid/squid_4.6-1+deb10u2.debian.tar.xz' squid_4.6-1+deb10u2.debian.tar.xz 64420 SHA256:38698bcb2340085843b502a8045292fcd911c266a9e653a1f7c7e0447a100154 Tim. -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
Re: [GLLUG] Retrieving debian source package.
I have managed to get it to work but I don't like it: (Obviously I also have a matching deb-src for buster-proposed-updates) root@dirac:/etc/apt/sources.list.d# cat debian-proposed.sources Types: deb URIs: http://ftp.uk.debian.org/debian Suites: buster-proposed-updates Components: main contrib non-free root@dirac:/etc/apt/preferences.d# cat proposed-pin-100 Package: * Pin: release v=10-updates,o=Debian,a=proposed-updates,n=buster-proposed-updates,l=Debian,c=non-free,b=amd64 Pin-Priority: 100 Package: * Pin: release v=10-updates,o=Debian,a=proposed-updates,n=buster-proposed-updates,l=Debian,c=contrib,b=amd64 Pin-Priority: 100 Package: * Pin: release v=10-updates,o=Debian,a=proposed-updates,n=buster-proposed-updates,l=Debian,c=main,b=amd64 Pin-Priority: 100 tim@dirac:~/git/pkgrebuild/squid$ apt-get --print-uris -t buster-proposed-updates source squid Reading package lists... Done Selected version '4.6-1+deb10u2' (buster-proposed-updates) for squid NOTICE: 'squid' packaging is maintained in the 'Git' version control system at: https://salsa.debian.org/squid-team/squid.git Please use: git clone https://salsa.debian.org/squid-team/squid.git to retrieve the latest (possibly unreleased) updates to the package. Need to get 5,241 kB of source archives. 'http://ftp.uk.debian.org/debian/pool/main/s/squid/squid_4.6-1+deb10u2.dsc' squid_4.6-1+deb10u2.dsc 2674 SHA256:6642185cf2a43854da25982f7a6a8550439d172dd69183ffc5fccb6538f46641 'http://ftp.uk.debian.org/debian/pool/main/s/squid/squid_4.6.orig.tar.gz' squid_4.6.orig.tar.gz 5174095 SHA256:190f5c015624f53279e5376749b08192f4023219398db3a40892d484513701c7 'http://ftp.uk.debian.org/debian/pool/main/s/squid/squid_4.6-1+deb10u2.debian.tar.xz' squid_4.6-1+deb10u2.debian.tar.xz 64420 SHA256:38698bcb2340085843b502a8045292fcd911c266a9e653a1f7c7e0447a100154 Tim. On Sun, 12 Jul 2020, Tim Woodall via GLLUG wrote: On Sun, 12 Jul 2020, James Courtier-Dutton via GLLUG wrote: On Sun, 12 Jul 2020 at 10:14, Tim Woodall via GLLUG wrote: Hi All, I'm struggling to work out how to retrieve a debian source package. I get this: tim@dirac:~/git/pkgrebuild/squid$ apt-get --print-uris -t buster source squid Reading package lists... Done E: Can not find version '4.6-1+deb10u2' of package 'squid' E: Unable to find a source package for squid It should just work. do you have the src entries in you /etc/apt/sources.list ? (or in sources.list.d) e.g. (This is the ubuntu equivalent, but the debian line should look similar) deb-src http://gb.archive.ubuntu.com/ubuntu/ bionic-updates main restricted Thanks. I _think_ I have the correct deb src: root@dirac:/etc/apt/sources.list.d# cat debian-security-src.sources Types: deb-src URIs: http://ftp.uk.debian.org/debian Suites: buster-updates Components: main contrib non-free Hit:6 http://ftp.uk.debian.org/debian buster-updates InRelease Hit:7 http://ftp.uk.debian.org/debian buster InRelease Hit:8 http://ftp.uk.debian.org/debian testing InRelease Hit:9 http://ftp.uk.debian.org/debian sid InRelease Reading package lists... Done root@dirac:/var/lib/apt/lists# ls -ltr *main_source_Sources -rw-r--r-- 1 root root 40133547 May 9 09:56 ftp.uk.debian.org_debian_dists_buster_main_source_Sources -rw-r--r-- 1 root root11729 Jun 13 20:56 ftp.uk.debian.org_debian_dists_buster-updates_main_source_Sources -rw-r--r-- 1 root root 42526842 Jul 12 08:57 ftp.uk.debian.org_debian_dists_testing_main_source_Sources -rw-r--r-- 1 root root 45902184 Jul 12 08:57 ftp.uk.debian.org_debian_dists_sid_main_source_Sources Which matches ftp.debian.org (I did wonder if the ftp.uk.debian.org mirror was out of date for some reason: Index of /debian/dists/stable-updates/main/source [ICO] Name Last modified Size [PARENTDIR] Parent Directory - [ ] Release 2019-07-06 11:27 111 [DIR] Sources.diff/ 2020-07-12 08:19 - [ ] Sources.gz 2020-06-13 19:56 3.9K [ ] Sources.xz 2020-06-13 19:56 3.6K [DIR] by-hash/ 2017-06-17 11:56 - (Only difference is a timezone difference) But the 4.6.1+deb10u2 exists in the binary list but not in the sources lists. In fact squid doesn't appear at all in ftp.uk.debian.org_debian_dists_buster-updates_main_source_Sources. I'd assumed it was something I'd done wrong at my end but I'm starting to suspect that the Sources.gz/Sources.xz for buster-updates (stable-updates) is wrong. I've managed to find a reference to this version in proposed-updates: root@dirac:/var/lib/apt/lists# grep '4\.6-1+deb10u2' *Sources ftp.uk.debian.org_debian_dists_proposed-updates_main_source_Sources:Version: 4.6-1+deb10u2 ftp.uk.debian.org_debian_dists_proposed-updates_main_source_Sources: 6642185cf2a43854da25982f7a6a8550439d172dd69183ffc5fccb6538f46641 2674 squid_4.6-1+deb10u2.dsc ftp.uk.debian.org_debian_dists_proposed-updates_main_source_Sources: 38698bcb2340085843b502a8045292fcd911c266a9e653a1f7c7e0447a100154 64420 squid_4.6-1+deb10u2.debian.tar.xz Now I just have to work out how to get it to pull the source via
Re: [GLLUG] Retrieving debian source package.
On Sun, 12 Jul 2020, James Courtier-Dutton via GLLUG wrote: On Sun, 12 Jul 2020 at 10:14, Tim Woodall via GLLUG wrote: Hi All, I'm struggling to work out how to retrieve a debian source package. I get this: tim@dirac:~/git/pkgrebuild/squid$ apt-get --print-uris -t buster source squid Reading package lists... Done E: Can not find version '4.6-1+deb10u2' of package 'squid' E: Unable to find a source package for squid It should just work. do you have the src entries in you /etc/apt/sources.list ? (or in sources.list.d) e.g. (This is the ubuntu equivalent, but the debian line should look similar) deb-src http://gb.archive.ubuntu.com/ubuntu/ bionic-updates main restricted Thanks. I _think_ I have the correct deb src: root@dirac:/etc/apt/sources.list.d# cat debian-security-src.sources Types: deb-src URIs: http://ftp.uk.debian.org/debian Suites: buster-updates Components: main contrib non-free Hit:6 http://ftp.uk.debian.org/debian buster-updates InRelease Hit:7 http://ftp.uk.debian.org/debian buster InRelease Hit:8 http://ftp.uk.debian.org/debian testing InRelease Hit:9 http://ftp.uk.debian.org/debian sid InRelease Reading package lists... Done root@dirac:/var/lib/apt/lists# ls -ltr *main_source_Sources -rw-r--r-- 1 root root 40133547 May 9 09:56 ftp.uk.debian.org_debian_dists_buster_main_source_Sources -rw-r--r-- 1 root root11729 Jun 13 20:56 ftp.uk.debian.org_debian_dists_buster-updates_main_source_Sources -rw-r--r-- 1 root root 42526842 Jul 12 08:57 ftp.uk.debian.org_debian_dists_testing_main_source_Sources -rw-r--r-- 1 root root 45902184 Jul 12 08:57 ftp.uk.debian.org_debian_dists_sid_main_source_Sources Which matches ftp.debian.org (I did wonder if the ftp.uk.debian.org mirror was out of date for some reason: Index of /debian/dists/stable-updates/main/source [ICO] Name Last modified Size [PARENTDIR] Parent Directory - [ ] Release 2019-07-06 11:27 111 [DIR] Sources.diff/ 2020-07-12 08:19 - [ ] Sources.gz 2020-06-13 19:56 3.9K [ ] Sources.xz 2020-06-13 19:56 3.6K [DIR] by-hash/ 2017-06-17 11:56 - (Only difference is a timezone difference) But the 4.6.1+deb10u2 exists in the binary list but not in the sources lists. In fact squid doesn't appear at all in ftp.uk.debian.org_debian_dists_buster-updates_main_source_Sources. I'd assumed it was something I'd done wrong at my end but I'm starting to suspect that the Sources.gz/Sources.xz for buster-updates (stable-updates) is wrong. I've managed to find a reference to this version in proposed-updates: root@dirac:/var/lib/apt/lists# grep '4\.6-1+deb10u2' *Sources ftp.uk.debian.org_debian_dists_proposed-updates_main_source_Sources:Version: 4.6-1+deb10u2 ftp.uk.debian.org_debian_dists_proposed-updates_main_source_Sources: 6642185cf2a43854da25982f7a6a8550439d172dd69183ffc5fccb6538f46641 2674 squid_4.6-1+deb10u2.dsc ftp.uk.debian.org_debian_dists_proposed-updates_main_source_Sources: 38698bcb2340085843b502a8045292fcd911c266a9e653a1f7c7e0447a100154 64420 squid_4.6-1+deb10u2.debian.tar.xz Now I just have to work out how to get it to pull the source via this (I don't want to include proposed updates in my binary sources but perhaps I'll have to and then pin it at a very low priority.) Tim. -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
[GLLUG] Retrieving debian source package.
Hi All, I'm struggling to work out how to retrieve a debian source package. I get this: tim@dirac:~/git/pkgrebuild/squid$ apt-get --print-uris -t buster source squid Reading package lists... Done E: Can not find version '4.6-1+deb10u2' of package 'squid' E: Unable to find a source package for squid I can see the source packages in http://ftp.uk.debian.org/ I have this in my lists: Package: squid Binary: squid3, squid, squid-common, squidclient, squid-cgi, squid-purge Version: 4.6-1+deb10u1 Maintainer: Luigi Gangitano Uploaders: Santiago Garcia Mantinan And there's nothing for squid in buster-updates sources which is where the Version: 4.6-1+deb10u2 binary package lives. Obviously I can manually download these source files and work from that but I'd like to understand how this is supposed to work. These are, I think, the relevant sources: root@dirac:/etc/apt/sources.list.d# grep "" *src.sources debian-security-src.sources:Types: deb-src debian-security-src.sources:URIs: http://ftp.uk.debian.org/debian debian-security-src.sources:Suites: buster-updates debian-security-src.sources:Components: main contrib non-free debian-security-src.sources: debian-src.sources:Types: deb-src debian-src.sources:URIs: http://ftp.uk.debian.org/debian debian-src.sources:Suites: buster testing sid debian-src.sources:Components: main contrib non-free debian-src.sources: Can anybody tell me what, if anything, I'm doing wrong? -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
Re: [GLLUG] KVM Performance
On Tue, 9 Jun 2020, Ken Smith via GLLUG wrote: Hi All, While in lockdown I decided to do some performance testing on KVM. I had believed that passing a block device through to a guest rather than using a QCOW2 file would get better performance. I wanted to see whether that was true and indeed whether using iSCSI storage was any better/worse. Interesting, I've been looking into this myself trying to improve performance/reduce cpu usage. This is a random file I happened to have lying around: scp _usr.dmp localhost:/mnt/nobackup/ _usr.dmp 100% 1990MB 149.9MB/s 00:13 Using nc (no encryption) time cat _usr.dmp >/dev/tcp/::1/ real0m5.617s When I copy it over the network (1Gbit) I get: scp _usr.dmp xen17:/dev/shm/ _usr.dmp 100% 1990MB 55.5MB/s 00:35 time cat _usr.dmp >/dev/tcp/fe80::d250:99ff:fec1:5e59%usb0/ real0m19.093s (This is pretty close to the theoretical maximum for the network!) Onto a virtual host that is running on xen17 #vm writing to /dev/zero time cat _usr.dmp >/dev/tcp/fe80::216:3eff:fee0:7253%usb0/ real0m19.798s #vm writing to an iscsi device (on the xen17 host) time cat _usr.dmp >/dev/tcp/fe80::216:3eff:fee0:7253%usb0/ real0m40.941s #using ssh: scp _usr.dmp debootstrap17:/mnt/tmp/x _usr.dmp 100% 1990MB 26.9MB/s 01:14 #And when the vm has the device mounted as a raw device, not via iscsi: time cat _usr.dmp >/dev/tcp/fe80::216:3eff:fee0:7253%usb0/ real0m34.968s And via SSH: scp _usr.dmp debootstrap17:/mnt/tmp/x _usr.dmp 100% 1990MB 30.1MB/s 01:06 In my particular case, using ssh to move files on the lan is by far the biggest hit and ssh tends to be used for everything nowadays. I will probably patch ssh at some point to allow the null cipher so encryption can be disabled in the .ssh/config file on a per host basis. xen17 is an Intel(R) Celeron(R) CPU J1900 @ 1.99GHz with 16GB ram and the source machine was a Intel(R) Core(TM) i3-7100U CPU @ 2.40GHz Tim. My test hardware is quite modest and this may adversely have affected what I measured. The processor is a Intel Core2 6300 @ 1.86GHz with VT-X support. It shows 3733 Bogomips at startup. There's 8GB RAM and an Intel 82801HB SATA controller on a Gigabyte MB. The disks are two 3TB SATA 7200RPM set up with a Raid 1 LVM Ext3 partition as well as other non-Raid partitions to use to test. I used Fedora 32 as the KVM host and my testing was with Centos 8 as a guest. On the host I got 60MB/s write and 143 MB/s read on Raid1/LVM/Ext3. I wrote/read 10GB files using dd. 10Gb so as to overflow any memory based caching. Without LVM that changed to 80 MB/s write and 149 MB/s read. I tried all kinds of VM setups. Normal QCOW2, pass though of block devices Raid/LVM and Non-Raid/LVM. I consistently got around 14.5 MB/s write and 16.5 MB/s read. Similar figures with iSCSI operating from both file based devices and block devices on the same host. The best I got by tweaking the performance settings in KVM was a modest improvement to 15 MB/s write and 17 MB/s read. As a reference point I did a test on a configuration that has Centos 6 on Hyper-V on an HP ML350 with SATA 7200 rpm disks. I appreciate that's much more capable hardware, although SATA rather than SAS, but I measured 176 MB/s write and 331 MB/s read. That system is using a file on the underlying NTFS file system to provide a block device to the Centos 6 VM. I also tried booting the C8 guest via iSCSI on a Centos6 Laptop, which worked fine on a 1G network. I measured 16.8 MB/s write and 23.1 MB/s read that way. I noticed an increase in processor load while running my DD tests, although I didn't take any actual measurements. What to conclude? Is the hardware just not fast enough? Are newer processors better at abstracting the VM guests with less performance impact? What am I missing?? Any thoughts from virtualisation experts here most welcome. Thanks Ken -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
Re: [GLLUG] Useful little cute box full of IP glue
On Tue, 3 Mar 2020, James Roberts via GLLUG wrote: It's not a major issue but it's annoying. I can't even find documentation to tell me if these init scripts ought to work. There's nothing in the log. Hmm, irritating. But again for myself, I wouldn't be using this little box for anything core - just for glue. It's not critical for me otherwise I'd be hacking the startup to find out what is going on. I can always work around this failure but it's conceivable that a power outage leading to a boot failure might leave me with having to configure ipv4 to get access to the IPMI if I'm trying to fix things remotely. (Another IPv6 annoyance, my IPMI will only do IPv6 via SLAAC - I can't get a static IPv6 to work - ipv6 isn't documented as supported so I can't really complain. But it's why I want a fallback RA source) -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
Re: [GLLUG] Useful little cute box full of IP glue
On Mon, 2 Mar 2020, James Roberts via GLLUG wrote: On 02/03/2020 07:54, Tim Woodall via GLLUG wrote: 1. One of them periodically locks up in a most peculiar way : I can ssh in via ethernet, Devices can associate (it's running as an AP,) but it appears that no (useful) traffic makes it across the bridge from ethernet to wifi. Even a reboot doesn't fix, it has to be powercycled. Faced with these sorts of issues on anything digital I always first suspect the PSU Indeed - and my tweaks involve ensuring that it's getting exactly 5v0. I think it was getting slightly more - and so why I suspect overheating under load. ... 3. Related to 2 but there's poor documentation on anything other than the web-gui. Go even slightly 'off-piste' and you are on your own. I've debated switching to rasbian for this reason alone (on a RPi) https://openwrt.org/docs/start ain't so bad... though Debian has better doc. But I still can't find anything about what I need. I have this (default from package install) # ls -l /etc/rc.d/S50radvd lrwxrwxrwx1 root root15 Nov 2 08:09 /etc/rc.d/S50radvd -> ../init.d/radvd and radvd starts as expected when I run /etc/init.d/radvd start But radvd does not start on boot but I can find no clue as to where the problem might be. It's not a major issue but it's annoying. I can't even find documentation to tell me if these init scripts ought to work. There's nothing in the log. Tim. -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
Re: [GLLUG] Useful little cute box full of IP glue
On Thu, 6 Feb 2020, James Roberts via GLLUG wrote: Anyway the device is this: https://www.gl-inet.com/products/gl-mt300n-v2/ Available from e.g. Amazon worldwide. It's got WiFi and two NICs and USB and micro-USB power, and runs OpenWRT which is accessible at the second menu level and so it's highly tweakable: not that I have had to tweak it... it has many VPN providers pre-set and supports OpenVPN and Wireguard. I paid ?24 for one, at that price it can glue lots of stuff together. Just thought I'd mention it. It's not a recommendation as such - it might break in a week - but I doubt it. There's various other models. And it's cute :) I'm using three of them. Mostly very good but here are a few annoyances I've come across: 1. One of them periodically locks up in a most peculiar way : I can ssh in via ethernet, Devices can associate (it's running as an AP,) but it appears that no (useful) traffic makes it across the bridge from ethernet to wifi. Even a reboot doesn't fix, it has to be powercycled. (it's possible this is heat related and I've made some tweaks this weekend so we'll see) 2. I've turned off almost everything (including the web gui). I've installed radvd but I cannot seem to make it start at boot. 3. Related to 2 but there's poor documentation on anything other than the web-gui. Go even slightly 'off-piste' and you are on your own. I've debated switching to rasbian for this reason alone (on a RPi) -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
[GLLUG] radvd leaking memory
Hi, Last night radvd got killed by the oom killer Feb 4 02:32:11 firewall17 vmunix: [1762825.239631] [ pid ] uid tgid total_vm rss pgtables_bytes swapents oom_score_adj name Feb 4 02:32:11 firewall17 vmunix: [1762825.239671] [ 3882] 105 3882 6849019387 58163248648 0 radvd When I look on another host I see that it's rather larger than I would have expected: 3247 radvd 20 0 177228 41016556 S 0.0 24.0 16:07.26 radvd After a bounce it looks better: 1030 radvd 20 02444 1616 1476 S 0.0 0.9 0:00.01 radvd I cannot find anything about radvd having memory leaks. Does anyone know if this large memory footprint is expected (I'm running it on a VM with not much memory and I can increase that if necessary)? I can obviously restart it to avoid this issue. I wonder if it could be related to VPN interfaces that are constantly being created and removed. Tim. -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
Re: [GLLUG] Squid thinks time is an hour in the past
Found it - I needed: refresh_pattern ^http://aptmirror17.home.woodall.me.uk/ 0 0% 0 refresh-ims in my squid.conf. I still don't understand why the times seem to be an hour out but that wasn't the source of my problem after all. Tim. On Sun, 15 Dec 2019, Tim Woodall via GLLUG wrote: Hi, Got a bizarre problem with a squid cache. It's as though it thinks the machine is on BST. einstein:/var/log/squid# ls -l access.log -rw-r- 1 proxy proxy 184889 Dec 15 19:04 access.log einstein:/var/log/squid# tail -1 access.log 1576436641.982 62463 2001:8b0:fb02:8007::128 TCP_TUNNEL/200 3806 CONNECT shavar.services.mozilla.com:443 - HIER_DIRECT/52.25.50.137 - einstein:/var/log/squid# date -d '1/1/70+1576436641.982secs' Sun Dec 15 18:04:01 GMT 2019 einstein:/var/log/squid# date Sun Dec 15 19:06:11 GMT 2019 einstein:/var/log/squid# cat /etc/timezone Europe/London einstein:/var/log/squid# ls -l /mnt/mirror/ftp/mirror/local/pool/main/d/default-resolv-conf-1.0.deb -rw-r--r-- 1 root root 822 Dec 15 18:38 /mnt/mirror/ftp/mirror/local/pool/main/d/default-resolv-conf-1.0.deb einstein:/var/log/squid# grep default-resolv- access.log 1576401874.161 8 2001:8b0:bfcd:100:216:3eff:fee0:7253 TCP_MEM_HIT/200 1339 GET http://aptmirror17.home.woodall.me.uk/local/pool/main/d/default-resolv-conf-1.0.deb - HIER_NONE/- application/x-debian-package 1576406622.851 0 2001:8b0:bfcd:100:216:3eff:fee0:7253 TCP_MEM_HIT/200 1339 GET http://aptmirror17.home.woodall.me.uk/local/pool/main/d/default-resolv-conf-1.0.deb - HIER_NONE/- application/x-debian-package 1576429866.730 0 2001:8b0:bfcd:100:216:3eff:fee1:7253 TCP_MEM_HIT/200 1339 GET http://aptmirror17.home.woodall.me.uk/local/pool/main/d/default-resolv-conf-1.0.deb - HIER_NONE/- application/x-debian-package 1576431078.518 0 2001:8b0:bfcd:100:216:3eff:fee1:7253 TCP_MEM_HIT/200 1339 GET http://aptmirror17.home.woodall.me.uk/local/pool/main/d/default-resolv-conf-1.0.deb - HIER_NONE/- application/x-debian-package 1576435503.627 8 2001:8b0:bfcd:100:216:3eff:fee0:7253 TCP_MEM_HIT/200 1339 GET http://aptmirror17.home.woodall.me.uk/local/pool/main/d/default-resolv-conf-1.0.deb - HIER_NONE/- application/x-debian-package 1576435505.662 0 2001:8b0:bfcd:100:216:3eff:fee0:7253 TCP_MEM_HIT/200 1339 GET http://aptmirror17.home.woodall.me.uk/local/pool/main/d/default-resolv-conf-1.0.deb - HIER_NONE/- application/x-debian-package 1576436448.060 0 2001:8b0:bfcd:100:216:3eff:fee0:7253 TCP_MEM_HIT/200 1339 GET http://aptmirror17.home.woodall.me.uk/local/pool/main/d/default-resolv-conf-1.0.deb - HIER_NONE/- application/x-debian-package 1576436450.111 0 2001:8b0:bfcd:100:216:3eff:fee0:7253 TCP_MEM_HIT/200 1339 GET http://aptmirror17.home.woodall.me.uk/local/pool/main/d/default-resolv-conf-1.0.deb - HIER_NONE/- application/x-debian-package As you can see, the access log was last written at 19:04 but the timestamp squid has written into the file is 18:04. The time on the machine is correct. This has been bugging me for a while. I have a local repo for packages and when I update one, and bump the version number, I have to restart squid in order to flush the old package. I've taken the time to investigate what could be wrong today. Hopefully, at 19:38 the new package will start working (instead of getting a "File has unexpected size" error.) proving my time issue. I can see that I'm getting a TCP_MEM_HIT/200 from the cache - and so the new file is not (yet) being served to the client. Has anyone seen anything like this before? Have I missed a config setting somewhere? I've scanned though all 8000 lines of /etc/squid/squid.conf but I didn't see anything that appeared relevant but I could easily have missed something. Squid was restarted on 13th December (in fact the entire machine was rebooted then) so it's not a very long lived process getting confused about timezone changes. Tim. -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
[GLLUG] Squid thinks time is an hour in the past
Hi, Got a bizarre problem with a squid cache. It's as though it thinks the machine is on BST. einstein:/var/log/squid# ls -l access.log -rw-r- 1 proxy proxy 184889 Dec 15 19:04 access.log einstein:/var/log/squid# tail -1 access.log 1576436641.982 62463 2001:8b0:fb02:8007::128 TCP_TUNNEL/200 3806 CONNECT shavar.services.mozilla.com:443 - HIER_DIRECT/52.25.50.137 - einstein:/var/log/squid# date -d '1/1/70+1576436641.982secs' Sun Dec 15 18:04:01 GMT 2019 einstein:/var/log/squid# date Sun Dec 15 19:06:11 GMT 2019 einstein:/var/log/squid# cat /etc/timezone Europe/London einstein:/var/log/squid# ls -l /mnt/mirror/ftp/mirror/local/pool/main/d/default-resolv-conf-1.0.deb -rw-r--r-- 1 root root 822 Dec 15 18:38 /mnt/mirror/ftp/mirror/local/pool/main/d/default-resolv-conf-1.0.deb einstein:/var/log/squid# grep default-resolv- access.log 1576401874.161 8 2001:8b0:bfcd:100:216:3eff:fee0:7253 TCP_MEM_HIT/200 1339 GET http://aptmirror17.home.woodall.me.uk/local/pool/main/d/default-resolv-conf-1.0.deb - HIER_NONE/- application/x-debian-package 1576406622.851 0 2001:8b0:bfcd:100:216:3eff:fee0:7253 TCP_MEM_HIT/200 1339 GET http://aptmirror17.home.woodall.me.uk/local/pool/main/d/default-resolv-conf-1.0.deb - HIER_NONE/- application/x-debian-package 1576429866.730 0 2001:8b0:bfcd:100:216:3eff:fee1:7253 TCP_MEM_HIT/200 1339 GET http://aptmirror17.home.woodall.me.uk/local/pool/main/d/default-resolv-conf-1.0.deb - HIER_NONE/- application/x-debian-package 1576431078.518 0 2001:8b0:bfcd:100:216:3eff:fee1:7253 TCP_MEM_HIT/200 1339 GET http://aptmirror17.home.woodall.me.uk/local/pool/main/d/default-resolv-conf-1.0.deb - HIER_NONE/- application/x-debian-package 1576435503.627 8 2001:8b0:bfcd:100:216:3eff:fee0:7253 TCP_MEM_HIT/200 1339 GET http://aptmirror17.home.woodall.me.uk/local/pool/main/d/default-resolv-conf-1.0.deb - HIER_NONE/- application/x-debian-package 1576435505.662 0 2001:8b0:bfcd:100:216:3eff:fee0:7253 TCP_MEM_HIT/200 1339 GET http://aptmirror17.home.woodall.me.uk/local/pool/main/d/default-resolv-conf-1.0.deb - HIER_NONE/- application/x-debian-package 1576436448.060 0 2001:8b0:bfcd:100:216:3eff:fee0:7253 TCP_MEM_HIT/200 1339 GET http://aptmirror17.home.woodall.me.uk/local/pool/main/d/default-resolv-conf-1.0.deb - HIER_NONE/- application/x-debian-package 1576436450.111 0 2001:8b0:bfcd:100:216:3eff:fee0:7253 TCP_MEM_HIT/200 1339 GET http://aptmirror17.home.woodall.me.uk/local/pool/main/d/default-resolv-conf-1.0.deb - HIER_NONE/- application/x-debian-package As you can see, the access log was last written at 19:04 but the timestamp squid has written into the file is 18:04. The time on the machine is correct. This has been bugging me for a while. I have a local repo for packages and when I update one, and bump the version number, I have to restart squid in order to flush the old package. I've taken the time to investigate what could be wrong today. Hopefully, at 19:38 the new package will start working (instead of getting a "File has unexpected size" error.) proving my time issue. I can see that I'm getting a TCP_MEM_HIT/200 from the cache - and so the new file is not (yet) being served to the client. Has anyone seen anything like this before? Have I missed a config setting somewhere? I've scanned though all 8000 lines of /etc/squid/squid.conf but I didn't see anything that appeared relevant but I could easily have missed something. Squid was restarted on 13th December (in fact the entire machine was rebooted then) so it's not a very long lived process getting confused about timezone changes. Tim. -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
Re: [GLLUG] Free to a good home
I found the drives and network cards. 1x80GB (was two but one is dead) and 3x pci network cards (untested) Tim. On Mon, 2 Dec 2019, Tim Woodall via GLLUG wrote: I have two old via fanless mini-itx motherboards that will otherwise end up in landfill. One is PATA only, the other has a SATA port. Both have 1GB Transcend flash modules plugged directly into the primary IDE port that they boot from. 1GB memory module installed. One runs 686-pae kernel, the other 686 without pae. 2x250GB pata drives (I thought I had more and if they turn up then I'll include them too) Dual slot PCI riser - and I should have some PCI network cards - again I couldn't find them last night. Both have pico-psu plugged in to run fanless from 12v dc (no power supply included) If you would run them from a standard atx power supply then I'll keep these as they're the one bit I might potentially reuse. (There's a risk that removing them might break something - I suspect these have been plugged in from new and I have no way to test without them) There is no case and I have the backplane shield only for one of them. If you don't want to use the riser then you can stand them on anything. With the riser you'll need a case or other way to support things. I used them as firewalls many years ago. They are currently booted (have been up all night wiping the hard disks) and the onboard network port is working. I have no idea how stable they might be under load - they've been gathering dust for years! I'll also include ps2 kvm switch box and ps2 keyboard (motherboards also work with usb keyboard). I have two other kvm switches, one still in its packaging that are available to anyone who wants them. Collection london z1 near spitalfields market (or canary wharf bank street during office hours) or I will ship for the cost of postage but if they're DOA or lost in the post then I won't refund. (They are unusable without a powersupply. 12v 5.5mmx2.5mm. They're low power so with a splitter can both be run from a single 5A psu or will need 2x atx supplies.) No warranty. Tim. -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
[GLLUG] Free to a good home
I have two old via fanless mini-itx motherboards that will otherwise end up in landfill. One is PATA only, the other has a SATA port. Both have 1GB Transcend flash modules plugged directly into the primary IDE port that they boot from. 1GB memory module installed. One runs 686-pae kernel, the other 686 without pae. 2x250GB pata drives (I thought I had more and if they turn up then I'll include them too) Dual slot PCI riser - and I should have some PCI network cards - again I couldn't find them last night. Both have pico-psu plugged in to run fanless from 12v dc (no power supply included) If you would run them from a standard atx power supply then I'll keep these as they're the one bit I might potentially reuse. (There's a risk that removing them might break something - I suspect these have been plugged in from new and I have no way to test without them) There is no case and I have the backplane shield only for one of them. If you don't want to use the riser then you can stand them on anything. With the riser you'll need a case or other way to support things. I used them as firewalls many years ago. They are currently booted (have been up all night wiping the hard disks) and the onboard network port is working. I have no idea how stable they might be under load - they've been gathering dust for years! I'll also include ps2 kvm switch box and ps2 keyboard (motherboards also work with usb keyboard). I have two other kvm switches, one still in its packaging that are available to anyone who wants them. Collection london z1 near spitalfields market (or canary wharf bank street during office hours) or I will ship for the cost of postage but if they're DOA or lost in the post then I won't refund. (They are unusable without a powersupply. 12v 5.5mmx2.5mm. They're low power so with a splitter can both be run from a single 5A psu or will need 2x atx supplies.) No warranty. Tim. -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
[GLLUG] openwrt routing failing unexpectedly.
I'm having a routing problem that I don't understand. I'm trying to setup a backup route to allow me to access an ipmi console even when the normal router goes down. I'm trying to get an openwrt wireless router to advertise a low priority route but two things are happening that I don't expect: 1. It's seeing the route it's advertising. I don't expect that based on the kernel settings. 2. The route seems to be breaking the normal route even though it has a lower priority - higher metric. Good routing table: default from 2001:dead:beef:3::/64 via fe80::216:3eff:fee0:8001 dev wlan0 proto static metric 512 default from 2001:dead:beef:8003::/64 via fe80::216:3eff:fee1:8001 dev br-lan proto static metric 512 2001:dead:beef:3::/64 dev wlan0 proto static metric 256 2001:dead:beef:8003::/64 dev br-lan proto static metric 256 fe80::/64 dev br-lan proto kernel metric 256 fe80::/64 dev wlan0 proto kernel metric 256 fe80::/64 dev wlan0-1 proto kernel metric 256 Bad routing table: default from 2001:dead:beef:3::/64 via fe80::216:3eff:fee0:8001 dev wlan0 proto static metric 512 default from 2001:dead:beef:8003::/64 via fe80::216:3eff:fee1:8001 dev br-lan proto static metric 512 2001:dead:beef:3::/64 from 2001:dead:beef:8003::/64 via fe80::e695:6eff:fe43:8589 dev br-lan proto static metric 640 2001:dead:beef:3::/64 dev wlan0 proto static metric 256 2001:dead:beef:8003::/64 dev br-lan proto static metric 256 fe80::/64 dev br-lan proto kernel metric 256 fe80::/64 dev wlan0 proto kernel metric 256 fe80::/64 dev wlan0-1 proto kernel metric 256 The only difference is that extra 2001:dead:beef:3::/64 route. But I thought this should be ignored as it has a higher metric than the other 2001:dead:beef:3::/64 route. Am I misunderstanding something? And why is the route appearing in the first place? cat /proc/sys/net/ipv6/conf/*/accept_ra_from_local 0 0 0 0 0 0 0 0 0 0 0 0 The one bit that confuses me is the "from" in the routing table. That doesn't appear on my other machines and it's quoting the /64 on the interface, not the link local address that I would otherwise have expected. (I'd expect the from to be the same as the via address) Has anyone seen anything like this - or know where I'm going wrong? Tim. -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
Re: [GLLUG] Advice about my Freeance work
On Fri, 25 Oct 2019, John Winters via GLLUG wrote: On 25/10/2019 20:25, nickmount91 via GLLUG wrote:> Hi, [snip] I can upgrade my email to the professional version and associate it with a domain. Would that be a good start? Then i can spend some time installing an email server, learning about it and then use it for real. Does this sound a good plan? Are there any alternatives? Hi Nick, If you want to learn stuff then setting up your own domain and email server sounds like a good idea. Domain names are really very cheap. Personally I use Mythic Beasts to register my domains, but there are plenty of similar around. I would avoid using providers which do hyper-cheap stuff (?1 / year or the like) because they tend to put restrictions on what you can do. If you use a proper provider then it's totally your domain and you can control every aspect of it. For the e-mail server, your main requirement is for a fixed IP address. If you use a decent ISP (hint, hint: Andrews and Arnold) you may already have a fixed IP address. If not then your best bet might be to use a Virtual Private Server (VPS) from BitFolk or similar. Don't forget to set up DKIM and SPF on your mail server. Without that, your outgoing e-mails are more liable to be categorized as spam. If you have IPv6 connectivity then make sure you set it up for your IPv6 address(es) as well. I recently found my configuration was lacking even though it had been fine when I set it up. Whilst other mail servers were IPv4 only all was well, but as they moved to IPv6 they started seeing my mail as originating from my IPv6 address and thus not covered by my SPF configuration. Test by sending an e-mail to check-a...@verifier.port25.com A good project and it will teach you a lot, besides giving you a more professional looking e-mail address. I'll second what John says. If you're self hosting email and using it for clients to contact you then you want a backup solution. The last thing your clients should see is emails failing because your adsl/server is down. You also want to consider whether your backup MX will queue or receive mail. You will also discover spammers love going to backup MX first. If/when you solve this for yourself it's then a solution you can offer to your clients too. Another vote for AAISP. As well as static ip, they support reverse dns which is almost essential if you want to send mail. They give a full /48 for ipv6. While knowing ipv6 probably won't win you any clients now, maybe in 5-10 years being able to step in and solve a problem that the ipv4 only people don't understand might be important. Other things for SME that you can experiment with at home at reasonable cost: multiple adsl lines, load balancing, failover/redundancy. Which will then get you involved with policy/source based routing too. Again, learn it for both ipv4 and ipv6. AAISP get all this right too. I have two lines from them and it all works so seamlessly that when one line had a problem I didn't notice straight away because everything "just worked". Which brings me to the final thought re clients - your tooling and monitoring. It's a difficult problem - you don't want to be bothered with 'everything is ok' messages but you need to know that the 'there's a problem' email/text can get to you. Nothing gives you a better reputation than fixing a problem for a client before they realise something is wrong. -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
Re: [GLLUG] Multiple grub installs in xen guest
On Fri, 11 Oct 2019, Tim Woodall via GLLUG wrote: Does anyone know whether the default debian grub-xen stuff allows you to select the grub root? I have a bootable xen image that uses grub from /dev/xvda2. I also have one that uses grub from /dev/vg-mirror/boot. (the vg is inside the disk I export to the guest, not the vg of dom0) I want to be able to boot the former, but have the latter available to mount. But it is insistent that it will use the vg boot in favour of the raw ext3 one. I've tried extra="(xen/xvda2)" and extra="root=(xen/xvda2)" but neither seem to make a difference and it persists in using lvm/vg--mirror-boot. This weekend I'll have a look at the source for the grub-x86_64-xen.bin bootloader and tweak it if necessary but perhaps someone already knows how to do this? Looks like the extra parameter is completely ignored :-( There appears to be nothing in grub that is passed from xen. 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. I've built a trivial replacement for grub-x86_64-xen.bin that does the right thing for my particular case. Just a tiny tad annoying that there doesn't seem to be any other way to do this than build a specific file for each guest if there's more than one possible grub to boot. Tim. -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
[GLLUG] Multiple grub installs in xen guest
Does anyone know whether the default debian grub-xen stuff allows you to select the grub root? I have a bootable xen image that uses grub from /dev/xvda2. I also have one that uses grub from /dev/vg-mirror/boot. (the vg is inside the disk I export to the guest, not the vg of dom0) I want to be able to boot the former, but have the latter available to mount. But it is insistent that it will use the vg boot in favour of the raw ext3 one. I've tried extra="(xen/xvda2)" and extra="root=(xen/xvda2)" but neither seem to make a difference and it persists in using lvm/vg--mirror-boot. This weekend I'll have a look at the source for the grub-x86_64-xen.bin bootloader and tweak it if necessary but perhaps someone already knows how to do this? Tim. -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
[GLLUG] Speculative IPv6 probing
I'm seeing probes obviously attempting to hunt for machines on IPv6. These ips were all blocked by my firewall today alone: DST=2001:08b0:fb02:8100:0216:3eff:fee0: ... DST=2001:08b0:fb02:8100:0216:3eff:fee0:0020 DST=2001:08b0:fb02:8100:0216:3eff:fee0:7fff ... DST=2001:08b0:fb02:8100:0216:3eff:fee0:801f DST=2001:08b0:fb02:8100:0216:3eff:fee0:ffdf ... DST=2001:08b0:fb02:8100:0216:3eff:fee0: They've got most of the address right (which presumably they've got via a DNS lookup and assumed I'm using SLAAC - which I am) Is this going to be the state of IPv6 going forwards? Or am I specially privileged? Anyone else seeing anything like this. I'd have to go through my logs to be sure but I think this has only been happening in the last month or so. Tim. -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
