Unable to negotiate with 1.2.3.4 port 22: no matching host key type found. Their offer: ssh-rsa,ssh-dss

While trying to connect to an older esxi server I got the error message Unable to negotiate with 1.2.3.4 port 22: no matching host key type found. Their offer: ssh-rsa,ssh-dss

I was wondering.

The solution $EDITOR ~/.ssh/config

Host 1.2.3.4
    User root
    HostKeyAlgorithms=+ssh-dss

Remove hihonor bloat ware

1) Download ADB
2) Enable USB Debugging on your device
3) Connect to the computer and verify your device is listed with the command “adb devices”
4) Type “adb Shell”
5) Type “pm list packages”, this will show you all packages installed on phone.
6) Type “pm uninstall -k –user 0 com.huawei.search”
7) you should see the word “Sucess” pop up Well I removed some more bloat ware

pm uninstall -k --user 0 com.google.android.apps.books
pm uninstall -k --user 0 com.google.android.youtube
pm uninstall -k --user 0 com.google.android.apps.youtube.music
pm uninstall -k --user 0 com.google.android.apps.photos
pm uninstall -k --user 0 com.google.mainline.telemetry
pm uninstall -k --user 0 com.hihonor.android.fmradio
pm uninstall -k --user 0 com.hihonor.calendar
pm uninstall -k --user 0 com.hihonor.search
pm uninstall -k --user 0 com.pal.train
pm uninstall -k --user 0 com.hihonor.pcassistant
pm uninstall -k --user 0 com.google.android.apps.tachyon
pm uninstall -k --user 0 com.google.android.feedback
pm uninstall -k --user 0 com.hihonor.printservice
pm uninstall -k --user 0 com.hihonor.android.totemweather
pm uninstall -k --user 0 com.hihonor.android.chr
pm uninstall -k --user 0 com.hihonor.android.thememanager
pm uninstall -k --user 0 com.google.android.videos
pm uninstall -k --user 0 com.google.android.apps.messaging
pm uninstall -k --user 0 com.hihonor.id

proxmox qmp command blockdev-snapshot-delete-internal-sync failed

While trying to move a VM from one node to another I got the error message:

VM 100 qmp command ‘blockdev-snapshot-delete-internal-sync’ failed – Failed to get a snapshot list: Operation not supported

One snapshot was stuck and the VM locked. How to solve this?

qm unlock 100
qm listsnapshot 100
qm delsnapshot 100 preFirstBoot --force
qm unlock <ID>
qm listsnapshot <ID>
qm delsnapshot <ID> <snapname> --force

it might be that the snapshot will remain on the hard disk.

Happy unlocking :)

zfs snapshot send resume

zfs send ... |  ssh host2 zfs receive -s otherpool/new-fs

On the receiving side, get the opaque token with the DMU object #, offset stored in it

zfs send ... |  ssh host2 zfs receive -s otherpool/new-fs
zfs get receive_resume_token otherpool/new-fs
# 1-e604ea4bf-e0-789c63a2...

Re-start sending from the DMU object #, offset stored in the token

zfs send -t 1-e604ea4bf-e0-789c63a2... |  ssh host2 zfs receive -s otherpool/new-fs

If you don’t want to resume the send, abort to remove the partial state on the receiving system

zfs receive -A otherpool/new-fs

ZFS enable email notification

Edit

/etc/zfs/zed.d/zed.rc

uncomment

ZED_EMAIL_ADDR="mail@example.com" 

and add a valid email address.

uncomment

ZED_EMAIL_PROG="mail"

uncomment

ZED_EMAIL_OPTS="-s '@SUBJECT@' @ADDRESS@"

uncomment

ZED_NOTIFY_VERBOSE=0

if you want to get an email after every scrup set the value to 1

save the file and restart zed service

systemctl restart zed.service

failed Import ZFS pools by cache file

A single disk zpool “test” crashed on my server (the disk died). It was just for testing, so nothing dramatic. However, when I rebooted the server I got the error message “failed Import ZFS pools by cache file”.  A zpool destroy -f did not solve the problem. zpool status still showed the “test” pool. The other pool tank was still working.

What did help was

# disable the cache file for the existing pool(s)
zpool set cachefile=none tank
# delete the old pool file
rm -rf /etc/zfs/zpool.cache
# recreate if
touch /etc/zfs/zpool.cache
reboot
# re-enable the cache
zpool set cachefile=/etc/zfs/zpool.cache tank

Well, the cache file should be automatically updated when your pool configuration is changed, but with the crashed pool it did not.

resize2fs new size too large to be expressed in 32 bits

After virtualizing a real computer with an old Linux I wanted to increase the partition size of the data drive. But I got this warning: resize2fs new size too large to be expressed in 32 bits

How to solve this? I started the VM with gparted-live.iso

# check file system
e2fsck -f /dev/sdb1
# auf 64 bit ändern
resize2fs -b /dev/sdb1
# increase partition .... wait :D / optional coffee
resize2fs -p /dev/sdb1
# check file system
e2fsck -f /dev/sdb1

Done :)

iptables 101

How to do things with iptables. Safety first: How to reset everything.

sudo iptables -F
sudo iptables -X
sudo iptables -t nat -F
sudo iptables -t nat -X
sudo iptables -t mangle -F
sudo iptables -t mangle -X
Also, safety first: Don’t just copy something and run it on your server. You better understand what you are doing.
How to block a service?
Instead of using “DROP” you should use “REJECT –reject-with tcp-reset”. If you want to be able to access that service from the inside, you have to add an allow rule first.
sudo iptables -A INPUT -p tcp -s localhost --dport 3306 -j ACCEPT #mysql allow local
sudo iptables -A INPUT -p tcp --dport 3306 -j REJECT --reject-with tcp-reset #mysql

The “REJECT –reject-with tcp-reset” looks to the outside like there is no service running. A “DROP” will show that there is a firewall / iptables working.

Blocking an IP range

sudo iptables -A bannedDownloader -s 14.120.0.0/16 -j DROP

Disallow NTP queries

sudo iptables -A INPUT -p udp -s localhost --dport 123 -j ACCEPT #ntp allow local
sudo iptables -I INPUT -p udp --dport 123 -j REJECT #ntp

Block timestamp

sudo iptables -I INPUT 1 -p ICMP --icmp-type timestamp-request -j DROP
sudo iptables -I INPUT 1 -p ICMP --icmp-type timestamp-reply -j DROP
sudo iptables -A INPUT -p icmp --icmp-type 13 -j DROP

Influxdb 2.0 lessons learned

I played a bit with influxdb version 2.0.0, telegraf client and two of my raspberry pies.
On my oldest pi  a 1 B+ the telegraf client caused too much performance issues on that light weight single CPU and 480 MB of usable RAM. So I chose a simple bash script with curl to send the CPU temperature to influxdb.

#!/bin/bash
timestamp=$(date +%s)
temp=$(vcgencmd measure_temp)
curl -XPOST \
"https://flux.example.com/api/v2/write?org=none&bucket=pihole&precision=s" \
--header "Authorization: Token asas==" \
--data-raw "cpu-temperature,host=pihole ${temp//\'C/} ${timestamp}"

At first I was running influxdbd by hand. But I didn’t want the usual port of 9999 of the alpha version and I also wanted SSL encryption when I log into the backend. Pretty easy with the already running apache on that server.

<VirtualHost *:443>
	ServerName flux.example.com
	DocumentRoot /var/www/empty

	<Directory /var/www/empty>
		Options Indexes FollowSymLinks
		AllowOverride None
		Require all granted
	</Directory>

	ProxyPass / http://localhost:9999/
	ProxyPassReverse / http://localhost:9999/

	SSLEngine on
	SSLCertificateFile  fullchain.pem
	SSLCertificateKeyFile privkey.pem
</VirtualHost>

so far so good. Starting the influxdb by hand after a reboot or failing isn’t an option.  So I created by on systemd service file

sudo $EDITOR /lib/systemd/system/influxdb2.service

[Unit]
Description=InfluxDB 2.0 service file.
Documentation=https://v2.docs.influxdata.com/v2.0/get-started/
After=network-online.target

[Service]
User=influx
Group=influx
ExecStart=/usr/local/bin/influxd
Restart=on-failure

[Install]
WantedBy=multi-user.target

Do not forget to enable it :D sudo systemctl enable influxdb2

 

So far I made one observation. The telegraf client is doing a lot of DNS requests through the network. If I’m not wrong it does it for every request. If you look at the graphic you see that the bottom a big blue line. That is the DNS requests from telegraf. At some point around 20:00 You see a drop. Well there I change the flush interval to 120 seconds. Later at round 7:30 I wrote the IP and host name into /etc/hosts and the “noise” was gone. That is something you maybe want to do in your devices, too to save some bandwidth and energy.

Posts Tagged linux

Archives by Month: