Re: [DNG] Distribution upgrade issue
Den 2021-02-22 kl. 02:25, skrev Curtis Maurand via Dng: Steps for the upgrade. 1. patch system to latest ascii patch level. apt-get update && apt-get upgrade 2. edit the /etc/apt/sources.list to change the ascii entries to beowulf and I commented out the source package entries. 3. apt-get install devuan-keyring (error, already installed) 4. apt-get update 5. apt-get dist-upgrade I think you are supposed to have a 4b, "apt-get upgrade" in between. //PG ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Distribution upgrade issue
On 2/21/21 6:17 PM, Antony Stone wrote: On Sunday 21 February 2021 at 23:33:39, Curtis Maurand via Dng wrote: I found an issue with a distribution upgrade from ascii to beowulf. Please give at least an outline of how you performed that upgrade? This machine is running as kvm guest. It is Devuan Ascii. The only thing running on this machine that is not out of the box devuan is Rainloop. Rainloop is a webmail application that runs on a website, so not an issue and not involved. It uses PHP and is happy with anything 5.6 or higher. Except for that his server is running out of the box packages from deb.devuan.org. The machine has a full LAMP Stack on it. It is running ispconfig (https://ispconfig.org), but that's an app that runs on apache. It configs web and mail accounts. It has about 20 websites running on it. I previously got this upgrade to run on a different copy of this particular virtual machine, but changes had been made since a november snapshot. It also has postfix, amavisd-new, spamassassin, clamav, fuzzyocr and other tools related to taking apart mail messages, scanning them and putting them back together. It's a workhorse and I'm so glad that I ditched systemd and all the trouble that it brings. This very well could be a Debian issue. I will need to install a like debian machine of the appropriate version and upgrade it to see what happens. Steps for the upgrade. 1. patch system to latest ascii patch level. apt-get update && apt-get upgrade 2. edit the /etc/apt/sources.list to change the ascii entries to beowulf and I commented out the source package entries. 3. apt-get install devuan-keyring (error, already installed) 4. apt-get update 5. apt-get dist-upgrade First error almost immediate is that perl's net::SNMP is missing from my system and it's part of getting amavis to stop. I believe that the install script is trying to call amavis-snmp-agent to stop it, but I'm not using that, so hence the error. I started aptitude, found the package and installed it and issued apt-get --fix-broken install and moved on. Amavis again bombed on a permissions problem involving ownership of it's lock files and died. I couldn't stop amavis (service stop amavis) for the same error. I killed amavis manually. I deleted the lock and pid files in /var/run/amavis/ folder. apt-get --fix-broken install and continued on. Then the roundcube upgrade failed due to mysql not running. I did not stop it. I ignored the error and continued. Then mysql/maraidb got upgraded Then apache got upgraded Roundcube has dependencies upon the LAMP stack. It seems logical that the Roundcube upgrade would follow the LAMP stack upgrade since it's a php application. I don't know where or how the order of these things gets set, that's why I'm bringing it up, here. I'm not a developer. I'm just trying to report problems that I ran into. I am not complaining. These are not deal breakers or things that can't be fixed afterwards dpkg --configure roundcube for instance. They are just a nuisance. I found out about the perl thing while testing. not hard. While upgrading ascii, install libnet-snmp-perl. then the install skips right past it. Thanks for your help. Curtis During the upgrade mysql is stopped. later in the process the upgrade to roundcube is attempted. When that happens, the script can't make the mysql connection because mysql is not running. I had to go get the upgrade script from roundcube to update it's database manually. The roundcube upgrade should happen after the mysql/mariadb upgrade and mysql should be running. I find it somewhat hard to believe that this is a Devuan (rather than Debian) problem. Can you identify: 1. whether any of the packages involved in the upgrade have been forked by Devuan 2. whether a Debian Stretch system running the same applications upgrades to Buster without the same problems 3. which repositories you are fetching the various packages from This may help to identify whether: a) Devuan is causing the problems you experienced b) the same would have happened under Debian c) the problems are caused by some mismatch of package versions which can't be handled by a routine upgrade Regards, Antony. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] unsigned kernels - strange behaviour
Hi Erich, Erich Minderlein via Dng writes: > Hi > > tonight my ansible stopped execution with the message > > TASK [Reboot the box if kernel updated] > > fatal: [*$Hostname*]: FAILED! => {"changed": false, "elapsed": 0, "msg": > "Running reboot with local connection would reboot the control node.", > "rebooted": false} > > Now there are no new kernels to install, because the system is up to date. > Last kernel install was Feb 7 06:49 > > [...] FYI, kernel upgrades are *not* the only trigger for reboots. Other packages may requests reboots as well. Some that I (vaguely) recall from the top of my head include initramfs-tools and libc-bin. You may find a /var/run/needs-reboot (or similar, don't remember the exact name, nor location below /var) that is used as the trigger and contains the packages that want to trigger. A reboot will remove the file. # find /var -name '*reboot*' should list the file, if it still exists. Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Distribution upgrade issue
On Sunday 21 February 2021 at 23:33:39, Curtis Maurand via Dng wrote: > I found an issue with a distribution upgrade from ascii to beowulf. Please give at least an outline of how you performed that upgrade? > During the upgrade mysql is stopped. later in the process the upgrade to > roundcube is attempted. When that happens, the script can't make the mysql > connection because mysql is not running. > I had to go get the upgrade script from roundcube to update it's database > manually. The roundcube upgrade should happen after the mysql/mariadb > upgrade and mysql should be running. I find it somewhat hard to believe that this is a Devuan (rather than Debian) problem. Can you identify: 1. whether any of the packages involved in the upgrade have been forked by Devuan 2. whether a Debian Stretch system running the same applications upgrades to Buster without the same problems 3. which repositories you are fetching the various packages from This may help to identify whether: a) Devuan is causing the problems you experienced b) the same would have happened under Debian c) the problems are caused by some mismatch of package versions which can't be handled by a routine upgrade Regards, Antony. -- Success is a lousy teacher. It seduces smart people into thinking they can't lose. - William H Gates III Please reply to the list; please *don't* CC me. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Distribution upgrade issue
Hello all, Thank you for the great work that you do. I found an issue with a distribution upgrade from ascii to beowulf. This server has a lot going on, but it is a web and mail server with a webmail system on it. It runs Postfix, Amavisd-new, Spamassassin and a lot of other things. the webmail system uses roundcube. During the upgrade mysql is stopped. later in the process the upgrade to roundcube is attempted. When that happens, the script can't make the mysql connection because mysql is not running. Ok, so I started mysql and do the retry on roundcube and skep the questions, because before I started, roundcube was working. So the update connects to roundcube and lo it cannot do the upgrade because the upgrade to mysql has to happen first. I had to go get the upgrade script from roundcube to update it's database manually. The roundcube upgrade should happen after the mysql/mariadb upgrade and mysql should be running. During the amavis upgrade, amavis runs into a permissions problem it will not recover from involving it's lock files. I had to remove the lock files and continued with apt-get --fix-broken install to continue. I think amavis needs to be stopped first. Also the amavis upgrade fails if perls net::SNMP is not installed. I've had to revert back to a previous snapshot due to a different error that is solvable, but involves partition resizing (no space left on device an a too small partition *sigh*). That's a different problem altogether. It's of my own making. :-) Thanks for your attention, Curtis ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Assigning a specific subnet and address to a Devuan Beowulf Qemu guest
Networking for qemu is not that hard though better documentation is a praiseworthy aim. But there are an awful lot of variations both in what to achieve and in the ways in achieving it. These are some thoughts from me: Like for all qemu device emulations, the network setup arguments for qemu come in pairs: + one argument that declares the internal emulation device, and + another argument that declares to host side attachment. The connection between the two arguments is done by means of an identification label, where (for net emulation) the host attachment is "named" by the label using an "id=LABEL" option and the internal emulation device argument mentions it using a "netdev=LABEL" option, where thus the LABEL bit is your choosen name. If you leave out identifications then qemu makes guesses about how arguments go together; it invents labels "cleverly" and uses them "intelligently". Unfortunately most documentation relies on that hidden labelling and as a result things appear to work by magic. Further just for the sake of increased confusion, there is also an alternative combination or shortcut argument ("-nic") that lets you configure both the emulation and attachment in a single option collection. In your case you have declared a single internal device, the e1000, and linked that to one of the two host attachments by the label "mynet0". The other host attachment, "mybridge0", is dangling, i.e. not linked with any internal interface emulation device, which qemu advices about with the "no peer for mybridge0" warning. HOST SIDE ATTACHMENT The hands-on for the host side setup depends firstly on which type of host attachment it is. "user" and "bridge" are two host attachment types. The (currently) full list is "(tap|bridge|user|l2tpv3|vde|netmap|vhost-user|socket)". They are all configured in their own ways although typically they use the same or overlapping names of options with typically concordant uses of them. The qemu-system-x86 "man" page is rather good at describing the attachment types and their options. In my words: The "user" type attachment is a "pretend" attachment as it facilitates IP level networking for the guest without having networking presence as an actual host interface. There is little good to say about this attachment type except that it's the one to use if you don't want to know anything about anything. Well, not my preference at least. The "user" type attachment is especially peculiar as it includes a DHCP service for the guest with a client visible IP address for the host, even though the attachment is not associated with an interface. The "bridge" type attachment results in a host side tap interface that get added to (and remove from) a nominated bridge or bridge "br0" by default. The "tap" type attachment results in a host side tap interface seemingly without any bridge juggling. However, its default script option nominates the /etc/qemu-ifup script which adds the tap to the bridge, if any, nominated by a br option, or by default the bridge, if any,that facilitates the default route for the host at the time guest is started. The "vde" type attachment is also a "pretend" attachment but it facilitates full Ethernet level networking via VDE virtual networking, which typically is present as a tap interface on the host. In this case you set up a "VDE switch" with a tap, and then make qemu connect up to that via the sock option which is "/tmp/vde.ctl" by default (coincidentally the same as the default setting for a VDE switch). and so forth. CLIENT SIDE The hands-on for the client side is just normal network configuration. which parimarily depends on whether to use DHCP (in part or full) or static configuration. With the "user" type attachment, the client is not a full networking entity from the host (or outside) point of view as it only handles IP level transport. Other attachment types makes the client a full networking entity. To use DHCP the overall setup must of course include a DHCP server on the network of the host side attachment (or the built-in one of the "user" type attachment). etc. Ralph. On 21/02 03:08, Steve Litt wrote: > > On Thu, 18 Feb 2021 07:18:44 -0700 > Gabe Stanton via Dng wrote: > > > I'm sorry for the confusion. That was not the guide I used. I did find > > the guide I used. It seems pretty straight forward, and I believe it > > clears up all the confusion and questions caused by my previous email. > > > > https://www.debian.org/doc/manuals/debian-handbook/sect.virtualization.en.html#sect.lxc.network > > Thanks Gabe. The preceding link helped, but was not sufficient. > Although better than most, it shares the same ambiguities as the > others, including not telling whether they're referring to the metal > host or the VM guest when discussing TAPs, bridges, devices and the > like. Also, like most of the others, they don't specifically identify > what should go in the "id=" slots. > > Based
Re: [DNG] Assigning a specific subnet and address to a Devuan Beowulf Qemu guest
On Thu, 18 Feb 2021 07:18:44 -0700 Gabe Stanton via Dng wrote: > I'm sorry for the confusion. That was not the guide I used. I did find > the guide I used. It seems pretty straight forward, and I believe it > clears up all the confusion and questions caused by my previous email. > > https://www.debian.org/doc/manuals/debian-handbook/sect.virtualization.en.html#sect.lxc.network Thanks Gabe. The preceding link helped, but was not sufficient. Although better than most, it shares the same ambiguities as the others, including not telling whether they're referring to the metal host or the VM guest when discussing TAPs, bridges, devices and the like. Also, like most of the others, they don't specifically identify what should go in the "id=" slots. Based on the preceding link, I deduce that the TAP is created by the guest VM, in such a way that it attaches to the bridge created on the metal host, and therefore I have no need to create a TAP on the metal host. Here's my progress so far, based on the link you supply above and my other readings and experimentation: *** I build the bridge purely with ip commands. Also, I don't mess with the firewall (which perhaps has been my problem all along). I'll investigate this tomorrow. Below are some scripts and stuff I'm using. The following is upnet.sh, which I use to set up networking on the metal host, which happens to run Void Linux, which has no /etc/network/interfaces: = #!/bin/sh use_bridge=1 use_tap=0 dev="enp40s0" ipaddr_major="192.168.0.2" ipaddr_minor="192.168.0.102" gateway="192.168.0.1" error_tap_without_bridge(){ echo -n "ERROR: Can\'t set TAP without " echo -n "BRIDGE! " echo Aborting... exit 1 } enable_ip_forwarding(){ echo 1 > /proc/sys/net/ipv4/ip_forward } unset_everything(){ dev=$1 ip_maj=$2 ip_min=$3 gateway=$4 echo "Unsetting everything for $dev, $ip_maj and $ip_min" ip link set dev tap0 down brctl delif br0 tap0 ip link del tap0 ip link set dev br0 down ip addr del $ip_min/24 dev br0 ip addr del $ip_maj/24 dev br0 brctl delbr br0 ip link set dev $dev down ip addr del $ip_min/24 dev $dev ip addr del $ip_maj/24 dev $dev echo "" } set_hostname_and_localhost(){ echo "Setting hostname and localhost" hostname=`grep -v "^\s*#" /etc/hostname | head -n1` ip link set dev lo up echo "" } create_phys_device_link(){ dev=$1 echo Creating device link for $dev ip link set dev $dev up echo "" } set_phys_device_addr(){ dev=$1 ip_maj=$2 ip_min=$3 gateway=$4 echo -n "Setting physical device addresses " echo -n "$ip_maj " echo -n "and $ip_min " echo -n "for $physdev " echo "with gateway $gateway" ip link set dev $dev down ip addr add $ip_maj/24 dev $dev ip addr add $ip_min/24 dev $dev ip link set dev $dev up ip route add default via $gateway echo "" } set_bridge(){ dev=$1 ip_maj=$2 ip_min=$3 gateway=$4 echo Setting bridge for $dev echo -n "Creating and setting bridge addresses " echo -n "$ip_maj " echo -n "and $ip_min " echo -n "for $physdev " echo "with gateway $gateway" ip link add name br0 type bridge ip link set dev $dev master br0 ip addr add $ip_maj/24 dev br0 ip addr add $ip_min/24 dev br0 ip link set dev br0 up ip route add default via $gateway echo "" } set_tap(){ echo Setting tap ip tuntap add tap0 mode tap brctl addif br0 tap0 #ip addr add 192.168.0.66/24 dev tap0 ip link set dev tap0 up echo "" } show_networking(){ echo -n "Networking follows in 3 seconds..." sleep 3 echo "\n" echo "" echo "" ip -4 link echo ".." ip -4 addr echo ".." ip -4 route echo "" echo "" } echo "\nBegin upnet.sh" [ "$use_tap" = "1" ] && [ "$use_bridge" != "1" ] && \ error_tap_without_bridge unset_everything $dev $ipaddr_major $ipaddr_minor $gateway enable_ip_forwarding set_hostname_and_localhost create_phys_device_link $dev $ipaddr_major $ipaddr_minor $gateway [ "$use_bridge" = "1" ] || \ set_phys_device_addr $dev $ipaddr_major $ipaddr_minor $gateway [ "$use_bridge" = "1" ] && set_bridge $dev \ $ipaddr_major $ipaddr_minor $gateway [ "$use_tap" = "1" ] && \ set_tap $dev $ipaddr_major $ipaddr_minor $gateway show_networking = The preceding just builds br0 with ip addresses 192.168.0.2 and 192.168.0.102, default route (gateway) 192.168.0.1, for my metal host, and runs every time my metal host is rebooted (or it can be run any time). It has provisions to build a tap, or to not build a bridge and instead assign the IP addresses and default route to enp40s0 itself. The next shellscript runs on my metal host to launch a (Devuan) VM guest: =