_r9

Moderators
  • Content Count

    12
  • Joined

  • Last visited

About _r9

  • Rank
    Member

Contact Methods

  • Website URL
    https://www.rothirsch.tech

Recent Profile Visitors

637 profile views
  1. Yes. But I'm not sure about all dependencies. I already described a few of them above. But if anything goes wrong you still have all configuration files and your data inside the backup. So in a worst case scenario you would need to reinstall the software you're using and simply recover the configuration files from the backup. You can recover your home directory at anytime and if you gather a few insights about the software you're using you'd be able to transfer a single application from one system to another on runtime. A research with: whereis <your-application> an the knowledge about the distribution your using (What is systemd?) gives you that ability. But for this scenario it would be more simple to install the software on the new system and transfer the configuration files from the old one. Okay long story short. If you know what dependencies the installation of Armbian creates (e.g. The UUID= inside the /etc/fstab) you can simply recover all your data with rsync using the --exclude option. It's been a long time I did this so I cannot give you a complete example but if you did the rsync backup first you'll always (in worst case manually) be able to recover your system. Another way I just remembered, if you backup the MBR of your eMMC after installing your system you'd be able to recovery the system like following. Recover the MBR first, create the system partition and recover and overwrite the partition with rsync using your backup data. So you don't need to reinstall the armbian image first. But this one is not for "on runtime" recovery approaches. I have a research project about this. I did this approach on a few banana pis in the past. Maybe you can find a few code snippets in here. Backup https://github.com/rothirschtec/ARM-backup-recovery/blob/master/RTbackup.sh Recovery https://github.com/rothirschtec/ARM-backup-recovery/blob/master/RTrecovery.sh I got lost on this backup projects because the banana pi images made me crazy. But maybe I'll restart the development. So following the projects on github might be interesting. ; )
  2. You can simply backup your device with rsync -> https://wiki.archlinux.org/index.php/Rsync#Full_system_backup Because Armbian is Linux and Linux installs all it software as packages it doesn't depend on a registry like Windows. One big benefit that comes from this is, that you can simply make a "copy" from the whole system. Rsync, in that particular case is able to deal with symlinks and is therefore able to manage a complete image of your system. If the worst case happens and you need to setup your data on a different board you can simply recover it with these steps Write the Armbian image to the emmc disk Overwrite all the data with your rsync data You need to be aware of the /etc/fstab after a fresh installation the UUID might change. If you overwrite it with your old UUID the system might not boot again. On a full recovery you should also not overwrite following partitions "/dev/" "/proc/" "/sys/" "/tmp/" "/run/" "/mnt/" "/media/" "/boot/" To be safe you also need to save the related Armbian image to each backup. If you change, for example, from Armbian-Stretch to Armbian-Buster and you want to recover it you need to dd the image onto the SD card and overwrite it with your backup like described above. If you simply want to test configurations or new software you should in theory add a USB stick to your device and rsync the whole system to a directory on it. Please don't simply use these lines in your environment. Test such things always in a test environment ; ) Backup mount /dev/YOURUSBSTICK/ /media/usb-backups/ rsync -aAXv --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} / /media/usb-backups/VERSION/ Recovery rsync -aAXv --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found","/boot"} --delete /media/backups/VERSION/ / reboot rsync and SSH Okay now comes the best part. You can combine SSH with rsync to backup and recover your device over the network from another device. Adding this rsync to a cronjob you can create automated backups for your own without buying a backup software. The FLOSS way so to say ; ) If you're interested, I've tried to take some time off to develop a backup recovery environment in the past. It's written in bash and is still somewhat in alpha state but maybe you can find some code pieces that'll help you with your backups. https://github.com/rothirschtec/RT-Blog-SBE In the end, you get the ability to create a backup device with this script and configure it to backup multiple devices automatically.
  3. Tested this on clearfog base, banana pi m64, banana pi m2+ ## Building and providing The elastic team doesn't provide deb packages for ARM devices. But together with docker, we're able to build the main executable for it. We will create a build directory which includes anything to install filebeat on a ARM device. So please stay inside the build directory the whole time you are using this tutorial. mkdir build && cd $_ ## Prepare source code First we will download, check and extract the source code of filebeat. Source: https://www.elastic.co/downloads/past-releases/filebeat-7-6-2 wget https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-7.6.0-linux-x86.tar.gz wget https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-7.6.0-linux-x86.tar.gz.sha512 sha512sum filebeat-7.6.0-linux-x86.tar.gz Extract and prepare tar xfz filebeat-7.6.0-linux-x86.tar.gz --transform 's/filebeat-7.6.0-linux-x86/filebeat-latest/' ## Using docker Install docker on any machine you want. We use a host with Debian Buster installed. ### Install docker on a Debian Buster x64 machine sudo apt install apt-transport-https ca-certificates curl gnupg2 software-properties-common wget -q -O - https://download.docker.com/linux/debian/gpg | sudo apt-key add - sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/debian stretch stable apt update sudo apt install docker-ce Instantiate a go container for cross-compilation (Debian Buster x64) Using latest docker go image docker run -it --rm -v `pwd`:/build golang:1.14 /bin/bash Inside the "go" docker container create filebeat for arm modules.listand arm64 go get github.com/elastic/beats cd /go/src/github.com/elastic/beats/filebeat/ git checkout v7.6.0 GOARCH=arm go build cp filebeat /build/filebeat-arm GOARCH=arm64 go build cp filebeat /build/filebeat-arm64 exit You can find the filebeat executeable inside your build directory. Leave it there for the moment. ## Download installation scripts I wrote an install script and collected a few files from other filebeat installations and uploaded them to github.com. You can find any information on the github repository itself. So we will clone the repository to the build directory. git clone https://github.com/rothirschtec/RT-Blog-elastic.git ## Filebeat configuration Now you have to copy the filebeat.yml so that that the install.sh we'll use later on can move it to the right place. cp filebeat-latest/filebeat.yml my-filebeat.yml and change it to your needs vi my-filebeat.yml ## Other configurations There are other configurations that might interests you. cp filebeat-latest/modules.d/YOUR_MODULE.yml.disabled my-YOUR_MODULE.yml Change this files too vi my-YOUR_MODULE.yml The install script will loop through all .yml files starting with my- and will copy them to the right direction ## Ready for installation The build directory is ready to use. You are able to upload the build directory to a ARM server of your choice and execute the install.sh there. rsync -av --exclude={".git","*.tar.gz","*.tar.gz.sha512"} ../build/ server-of-your-choice:/opt/build/ ssh server-of-your-choice cd /opt/build/ bash /opt/build/RT-Blog-elastic/install.sh rm -rf /opt/build/ ## Modules You're able to enable modules with the installation script. Create a file called modules.list inside the build directory and write the modules separated by whitespaces like iptables system apache
  4. So I read through this thread and there are a few thoughts that came up. I believe when you want to solve a spam problem efficiently one needs to focus on the spam itself and not on the spammers. I'm dealing with lots of spam on my mailservers and manually blacklisting is the least efficient way to solve this problem. In my case 2000 - 10000 Spam mails a month. The main reasons why this is not a good practice are already described in a few posts inside this thread. Automated mail creation for example. So what are the real problems with spam posts? I think the most potential thread, if we focus on security, is that a user could get mislead to a dangerous URL. There is also the problem that the Armbian Forum could get misrelated to porn pages or other ugly stuff through google searching or other online indexes. Worst case would be if someone types porn stuff into the google search box and gets the Armbian forum as a result or someone finds a post that should help him and this post is full off ads. This would harm the forums image. So IMO the real problem is related to the URLs the spammers uses. So maybe there's a function like "URL registering"? So if a user wants to add a URL which is not known by Armbian he needs to register it with a small form or so and a moderator needs to approve the URL. Another concept could be that posts with unknown URLs needs to be approved even if they are changed after a while. So the system needs to run the approval recognition not only on new posts but on each change to. What's with the existing spam URLs? I don't know if such functions exists but if we could run through all posts with URLs (maybe inside the database) and disapprove all posts with unknown URLs then we have a list we can score. Moderators would need to approve all this posts again and register the URLs if they are valid. Maybe we should do this with a small amount of posts each. So we would need a function like "disapprove the first 100 posts with unknown URLs". May be we could assign each moderator a few posts automatically so he can approve 10 posts a week or so. 11 Moderators would solve 110 posts a week. I don't know how big the problem is but the year has 52 weeks so we could to a lot of work without really doing anything. I'm absolutely new to this forum so maybe this is all nonsense but hiring volunteering spamfilters does not seem to be the smart way.
  5. Hi Igor, it would be an honour to help you on your project. I highly respect this forum and I'm really interested in ARM Technologies and Debian based distributions. My hat's off to the guys at Armbian to manage a huge project like this Besides that I'm using SBCs for server solutions another attempt to get a deeper look into ARM technology was to deal with Banana Pi products on Amazon. This attempt cost me a lot of time and in the end I almost lost my company too. The product line of SinoVoip or Bipai Keji (HK) Limited got messier each month. After they fired my main supporter anything got worse. Since then I'm seeking for a new opportunity for my company to get a footstep into the ARM world. Especially the Armbian Forum. I ceased the Amazon sales last week. Therefore I have a few hours left each week for a new project. So the time would be perfect to support an opensource project. If you're interested, I'd looking forward to get to know each other on the Armbian Forum. What might interests you as well is that I worked as a first level supporter, almost for elder people, for 3 years. So I know my place if something gets out of control and people gets angry or confused. The only problem I may see is if you need moderators with short reaction times or too much hours each day. I think I can handle work like once, maybe twice, a day for something around an hour or so - 12/5. I'm looking forward to read you Best Regards, _r9
  6. @lex yes this file exists on both devices with following content cat /sys/class/hwmon/hwmon0/name f1072004mdiomii00
  7. Hey guys, thanks for helping me out and sorry for the late response. I checked the thermal_zone as @guidoldescriped cat /sys/devices/virtual/thermal/thermal_zone0/temp 84164 I also checked the link inside _/etc/armbianmonitor/datasources_ ls -l total 0 lrwxrwxrwx 1 root root 47 Aug 28 10:40 soctemp -> /sys/devices/virtual/thermal/thermal_zone0/temp It's all the same on the Clearfog pro as it is on the Clearfog base @lex I cannot find a value like *temp[0-9]_label* But maybe this output can help find /sys/devices/ |grep temp[0-9] /sys/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:04/mdio_bus/mv88e6xxx-0/mv88e6xxx-0:0f/hwmon/hwmon7/temp1_max_alarm /sys/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:04/mdio_bus/mv88e6xxx-0/mv88e6xxx-0:0f/hwmon/hwmon7/temp1_crit /sys/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:04/mdio_bus/mv88e6xxx-0/mv88e6xxx-0:0f/hwmon/hwmon7/temp1_input /sys/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:04/mdio_bus/mv88e6xxx-0/mv88e6xxx-0:04/hwmon/hwmon6/temp1_max_alarm /sys/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:04/mdio_bus/mv88e6xxx-0/mv88e6xxx-0:04/hwmon/hwmon6/temp1_crit /sys/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:04/mdio_bus/mv88e6xxx-0/mv88e6xxx-0:04/hwmon/hwmon6/temp1_input /sys/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:04/mdio_bus/mv88e6xxx-0/mv88e6xxx-0:02/hwmon/hwmon4/temp1_max_alarm /sys/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:04/mdio_bus/mv88e6xxx-0/mv88e6xxx-0:02/hwmon/hwmon4/temp1_crit /sys/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:04/mdio_bus/mv88e6xxx-0/mv88e6xxx-0:02/hwmon/hwmon4/temp1_input /sys/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:04/mdio_bus/mv88e6xxx-0/mv88e6xxx-0:00/hwmon/hwmon2/temp1_max_alarm /sys/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:04/mdio_bus/mv88e6xxx-0/mv88e6xxx-0:00/hwmon/hwmon2/temp1_crit /sys/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:04/mdio_bus/mv88e6xxx-0/mv88e6xxx-0:00/hwmon/hwmon2/temp1_input /sys/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:04/mdio_bus/mv88e6xxx-0/mv88e6xxx-0:03/hwmon/hwmon5/temp1_max_alarm /sys/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:04/mdio_bus/mv88e6xxx-0/mv88e6xxx-0:03/hwmon/hwmon5/temp1_crit /sys/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:04/mdio_bus/mv88e6xxx-0/mv88e6xxx-0:03/hwmon/hwmon5/temp1_input /sys/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:04/mdio_bus/mv88e6xxx-0/mv88e6xxx-0:01/hwmon/hwmon3/temp1_max_alarm /sys/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:04/mdio_bus/mv88e6xxx-0/mv88e6xxx-0:01/hwmon/hwmon3/temp1_crit /sys/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:04/mdio_bus/mv88e6xxx-0/mv88e6xxx-0:01/hwmon/hwmon3/temp1_input /sys/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:00/hwmon/hwmon0/temp1_max_alarm /sys/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:00/hwmon/hwmon0/temp1_crit /sys/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:00/hwmon/hwmon0/temp1_input /sys/devices/virtual/thermal/thermal_zone0/hwmon1/temp1_input @Igor I have also noticed that the *CpuFreq[1-9]: ... MHz* section is missing in the htop frontend too, on all of my _Clearfog Pro_ devices When I open up the /usr/bin/htop it looks like that there you can see the hardcoded files u: ^@^@^@show processes of a single user^@ H: ^@^@^@hide/show user process threads^@^@ K: ^@^@^@hide/show kernel threads^@^@^@^@ F: ^@^@^@cursor follows process^@^@ F6 + -: ^@^@^@expand/collapse tree^@^@^@^@ P M T: ^@^@^@sort by CPU%, MEM% or TIME^@^@ I: ^@^@^@invert sort order^@^@^@ F6 > .: ^@^@^@select sort column^@^@Environment of process %d - %s^@^@Could not read process environment.^@Refresh^@"^@^@^@/sys/class/thermal/thermal_zone0/temp^@^@^@/sys/devices/virtual/thermal/thermal_zone0/temp^@/sys/class/hwmon/hwmon0/temp1_input^@/sys/devices/system/cpu/cpu%d/cpufreq/cpuinfo_cur_freq^@^@/sys/devices/platform/soc/7081400.i2c/i2c-0/0-0036/regulator/regulator.1/microvolts^@/sys/devices/platform/soc/1f02400.i2c/i2c-4/4-0065/regulator/regulator.5/microvolts^@/sys/devices/platform/ff3c0000.i2c/i2c-0/0-001b/regulator/regulator.12/microvolts^@^@^@/sys/devices/platform/ff3c0000.i2c/i2c-0/0-0040/regulator/regulator.9/microvolts^@^@^@^@/sys/devices/system/cpu/cpu%d/cpufreq/cpuinfo_max_freq^@^@/proc/uptime^@^@^@^@%64lf^@^@^@/proc/loadavg^@^@^@%32lf %32lf %32lf %32d/%32d %32d^@^@^@^@/proc/sys/kernel/pid_max^@^@^@^@/proc/%d/environ^@^@^@^@ 0 Cancel^@^@^@ 1 SI The following files are available cat /sys/devices/virtual/thermal/thermal_zone0/temp 66548 cat /sys/class/hwmon/hwmon0/temp1_input 62000 cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq cat: /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq: No such file or directory cat /sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_cur_freq cat: /sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_cur_freq: No such file or directory This is all exactly the same on my Clearfog Base. But now I can see that on the Clearfog Base the CpuFreq is 0 Mhz. So the issue changed to Clearfog Base: Shows 0 MHz because the hardcoded files are missing Clerafog Pro: Doesn't show that sections at all. It looks like this htop doesn't have this features at all Aaaaaahhhhhh!!!! Ok inside htop on the Clearfog Pro's I had to configure the Frequency and Temperature. Solution Enter htop Press F2 Another Update On my Clearfog Pro does the file **/sys/devices/system/cpu/cpufreq/policy0/scaling_cur_freq** exist and its content switches between 800 and 1600 this is shown in htop On the Clearfog Base is the whole directory **/sys/devices/system/cpu/cpufreq/** empty
  8. That's really an open minded extension for htop. Fast and simple! I've recognized an issue with temperature on my clearfog pro with Debian buster and stretch. Clearfog Base (Debian Buster) works htop version buster: 2.2.0-3~armbian5.92+1 bpi-m64 (Debian Buster) works htop version buster: 2.2.0-3~armbian5.92+12.1.2-3 bpi-m2+ (Debian Stretch) works htop version stretch: 2.1.2-3 Clearfog pro (Debian Buster and Stretch) doesn't work on a stretch and a buster installation htop version buster: 2.2.0-3~armbian5.92+1 htop version stretch: 2.1.2-3
  9. Upgrade on a Banana Pi bpi-m2+ and on a Solid-Run Clearfog base also works like a charm I had a problem with my iptables rules. Buster changes the system to use nf_tables or so. I had no time yet to look deeper into this. So for whom that needs the iptables rules, you can switch back to iptables. update-alternatives --set iptables /usr/sbin/iptables-legacy
  10. @Igor Thanks for the work. Struggled around with an Icinga2 installation on a bpi-m64 with stretch. Upgraded to Debian Buster, installed the Icinga2 package from within the Debian repositories and everything works : )
  11. I summarized the content of a few sites and wrote a complete installation guide for Armbian on a Clearfog pro and Clearfog base. You will need a FAT formatted USB Stick where you can store the Armbian image and some bootloader files an USB A to microUSB B cable Clearfog Base or Pro with a power adapter Prepare installation files mkdir -p /opt/clearfog_installation cd /opt/clearfog_installation curl https://wiki.solid-run.com/lib/exe/fetch.php?media=products:a38x:software:debian:clearfog-emmc-v3.tar.gz --output clearfog-emmc-v3.tar.gz tar xfz clearfog-emmc-v3.tar.gz Copy following files to an USB stick mnt <your usb> /mnt/ mv u-boot-clearfog-base-mmc.kwb zImage armada-388-clearfog.dtb /mnt/ Put Armbian to the stick You have to create the _extlinux_ directory and put the _extlinux.conf_ into it. You'll need this do boot a linux image. With it you will be able to write the Armbian image to the eMMC memory mkdir -p /mnt/extlinux mv extlinux.conf /mnt/extlinux/ cd /mnt/extlinux/ Clearfog Pro wget https://dl.armbian.com/clearfogpro/Debian_stretch_next.7z Clearfog Base wget https://dl.armbian.com/clearfogbase/Debian_stretch_next.7z Extract and check integrity 7za e Debian_stretch_next.7z shasum -a 256 -c sha256sum.sha Armbian_*.img STRG+c cd /opt/clearfog_installation umount /mnt Next Steps Plug in USB stick to the Clearfog Plug in USB cable (USB A site) to the PC Plug in USB cable (microUSB B site) to the Clearfog Set Jumper to UART **0 1 0 0 1** PC The maintainer delivers *kwboot* for the installation. With it you can send the u-boot bootloader to the device ./kwboot -t -b u-boot-clearfog-base-uart.kwb /dev/ttyUSB0 Clearfog - Power up the Clearfog - Wait a few minutes of the U-Boot image to download - !! Hit a key to stop autoboot !! - Configure the eMMC to boot from hardware boot partition PC (kwboot terminal) mmc partconf 0 1 1 0 date reset run bootcmd_usb0 login with _root_ mount /dev/sda1 /mnt dd if=/mnt/extlinux/Armbian_5.59_Clearfogpro_Debian_stretch_next_4.14.66.img of=/dev/mmcblk0 bs=1M conv=fsync hdparm -z /dev/mmcblk0 umount /mnt/ mount /dev/mmcblk0p1 /mnt/ echo 0 > /sys/block/mmcblk0boot0/force_ro dd if=/mnt/usr/lib/linux-u-boot-next-clearfogpro_5.59_armhf/u-boot.mmc of=/dev/mmcblk0boot0 sed -i 's/emmc_fix=off/emmc_fix=on/g' /mnt/boot/armbianEnv.txt umount /mnt/ poweroff PC (a second terminal) killall kwboot screen /dev/ttyUSB0 115200 Clearfog Unplug power adapter Set jumpers to **0 0 1 1 1** Plugin power jack Now you should see Armbian booting up in the terminal were you executed the _screen_ command Sources First insights (armbian.com) Maintainers installation guide (wiki.solid-run.com) First hint for armbian bootloader installation (armbian.com) Final Armbian bootloader installation hint