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:
