I need to check out if it finally got available for OpenSuSE: [WayBack] CoreFreq – A Powerful CPU Monitoring Tool for Linux Systems
via:
Posted by jpluimers on 2018/05/07
I need to check out if it finally got available for OpenSuSE: [WayBack] CoreFreq – A Powerful CPU Monitoring Tool for Linux Systems
via:
Posted in *nix, *nix-tools, Linux, openSuSE, Power User, ps, SuSE Linux | 2 Comments »
Posted by jpluimers on 2018/04/23
A while ago, when upgrading from CPE_NAME="cpe:/o:opensuse:tumbleweed:20170206" to CPE_NAME="cpe:/o:opensuse:tumbleweed:20170213":
aRetrieving: monitoring-tools-1.14.0-4.2.x86_64.rpm ......................................................................................................[error]
File './x86_64/monitoring-tools-1.14.0-4.2.x86_64.rpm' not found on medium 'http://download.opensuse.org/repositories/server:/monitoring/openSUSE_Tumbleweed/'
What happened is that the local zypper configuration was out of sync with the repository. A zypper refresh solved that.
So I expanded my zypper-twup alias to always include the zypper refresh.
Then I updated the documentation from [old WayBack] openSUSE:Tumbleweed upgrade – openSUSE to [new WayBack] openSUSE:Tumbleweed upgrade – openSUSE.
Note you need an account at https://login.microfocus.com to logon to the various opensuse.org sites to make edits or post messages.
–jeroen
Posted in *nix, Linux, openSuSE, Power User, SuSE Linux, Tumbleweed | Leave a Comment »
Posted by jpluimers on 2018/04/08
OSC downloads for [archive.is] https://bugzilla.opensuse.org/show_bug.cgi?id=1084812
The binaries provided by Stefan Brüns, together with installation instructions are now in a git repository at [WayBack] wiert.me/public/linux/opensuse/tumbleweed/aarch64 a.k.a. arm64/1084182-fix-osc-binaries · GitLab.
Follow the steps in Applying the fixes on a broken system to at least temporarily get your system to work (a new zypper dist-upgrade might fail, so be careful with that).
The cause was some ARM A53 errata handling:
–jeroen
Posted in *nix, *nix-tools, Development, DVCS - Distributed Version Control, git, Hardware Development, Linux, openSuSE, Power User, Raspberry Pi, Source Code Management, SuSE Linux, Tumbleweed | Leave a Comment »
Posted by jpluimers on 2018/04/05
Before upgrading a Tumbleweed system, it makes sense to check which is your local and which is the on-line version. This is actually a tad more complicated than it sounds.
There are three versions involved:
aarch64 used on https://download.opensuse.org/ports/aarch64/tumbleweed/repo/oss/repodata/ file *-primary.xml.gz and http://download.opensuse.org/ports/aarch64/tumbleweed/repo/oss/aarch64/ in files openSUSE-release-*-1.1.aarch64.rpmThere is a mismatch between the last two as a side effect of decoupling the arm port a bit from the high checkin frequency of openSUSE:Factory; ARM simply has not enough power to build the snapshot in the same time Intel and PowerPC can do.
[WayBack] Dominique a.k.a. DimStar (Dim*) – A passionate openSUSE user thinks the last two are mismatched is a side effect off [WayBack] osc service remoterun operates on outdated sources (product builder) · Issue #4768 · openSUSE/open-build-service · GitHub.
He also tech-reviewed this post.
There are various ways to get your local version:
The easiest is to inspect the file /etc/os-release, for instance 20180208 in the file content:
NAME="openSUSE Tumbleweed" # VERSION="20180208 " ID=opensuse ID_LIKE="suse" VERSION_ID="20180208" PRETTY_NAME="openSUSE Tumbleweed" ANSI_COLOR="0;32" CPE_NAME="cpe:/o:opensuse:tumbleweed:20180208" BUG_REPORT_URL="https://bugs.opensuse.org" HOME_URL="https://www.opensuse.org/"
You can also perform rpm --query --provides openSUSE-release | grep "product(openSUSE)" which for the same install returned this product(openSUSE) = 20180208-0.
Finally, you can use zypper to query the installed product which also includes the version:
$ zypper search --installed-only --type product --details Loading repository data... Reading installed packages... S | Name | Type | Version | Arch | Repository ---+----------+---------+------------+---------+------------------ i+ | openSUSE | product | 20180228-0 | aarch64 | (System Packages)
I will explain this for the aarch64 architecture, but the mechanism holds for all architectures, it is just that the directory names vary.
Architectures and base directories you can use this mechanism with:
i586, i686 and x86_64
aarch64
armv6hl
armv7hl
ppc, ppc64 and ppc64le
s390x
Each architecture contains the version number in two kinds of places:
*-primary.xml.gz referenced from repomd.xml in the repodata subdirectory?P=openSUSE-release-2*Back to the aarch64 architecture:
Getting the version through repomd.xml is what zypper does based on a slight adoption of https://en.opensuse.org/openSUSE:Standards_Rpm_Metadata#Repository_layout resulting in release version 20180324:
Inspect https://download.opensuse.org/ports/aarch64/tumbleweed/repo/oss/repodata/repomd.xml for the name of *-primary.xml.gz (in this case https://download.opensuse.org/ports/aarch64/tumbleweed/repo/oss/repodata/d701c298b21d0b995c9560f9cfcc84685cb916deacc4f4c4a613a9b9d8f5aa57-primary.xml.gz
Download that .gz file and uncompress it
Inspect the *-primary.xml from it, look inside the metatadata root element for a package having a name element with value openSUSE-release: that packageelement now has a version element having a ver attribute containing the release version text.
Example file content:
<?xml version="1.0" encoding="UTF-8"?>
<metadata xmlns="http://linux.duke.edu/metadata/common" xmlns:rpm="http://linux.duke.edu/metadata/rpm" packages="35006">
<!-- ... -->
<package type="rpm">
<name>openSUSE-release</name>
<arch>aarch64</arch>
<version epoch="0" ver="20180324" rel="1.1"/>
<!-- ... -->
</package>
<!-- ... -->
</metadata>
Getting the version through the name of the openSUSE-release-2* package:
openSUSE-release-20180324-1.1.aarch64.rpm indicating release version 20180324I will explain this for the aarch64 architecture, but the mechanism holds for all architectures that build on openQA, it is just that the directory names vary and not all architectures are running on openQA.
Architectures and base directories you can use this mechanism with:
i586, i686 and x86_64 (let’s call this platform Intel)
x86_64 and some i586)x86_64)aarch64 (let’s call this platform ARM)
ppc, ppc64 and ppc64le (let’s call this platform PowerPC)
ppc64 and ppc64le)s390x (let’s call this platform System Z)
Architectures not on openQA:
armv6hlarmv7hlEach platform contains the version number in two kinds of places:
media.1/media and media.1/productsBack to the aarch64 architecture on the ARM platform:
https://download.opensuse.org/ports/aarch64/tumbleweed/repo/oss/media.1/media
openSUSE - openSUSE-20180322-aarch64-Build46.1-Media
openSUSE-20180322-aarch64-Build46.1
1
https://download.opensuse.org/ports/aarch64/tumbleweed/repo/oss/media.1/products
/ openSUSE 20180322-0
https://openqa.opensuse.org/group_overview/3 openSUSE Tumbleweed AArch64
... Build20180322 (10 days ago) testing ...
–jeroen
Posted in *nix, Linux, openSuSE, Power User, SuSE Linux, Tumbleweed | Leave a Comment »
Posted by jpluimers on 2018/04/02
I resolved my issue with tshark, but that’s not available on all systems neither is dnstop. Most systems do have tcpdump though.
Anyway, some links:
–jeroen
Posted in *nix, *nix-tools, DNS, Internet, Linux, openSuSE, Power User, SuSE Linux | Leave a Comment »
Posted by jpluimers on 2018/03/28
- Use the screen quit command (normally ctrl-A ctrl-\).
- Use the command mode of screen (normally ctrl-A :) then type
quitorhelpfor more commands
This will quit screen and release the TTY serial port connection.
Related: hooking screen to a TTY serial port connection in [WayBack] The woods and trees of OpenSuSE on single-board computers – image abbreviations – and getting it installed using OS X
–jeroen
via:
Posted in *nix, *nix-tools, Linux, openSuSE, Power User, SuSE Linux | Leave a Comment »
Posted by jpluimers on 2018/03/20
Quite a while back, I got attended to Ben, blogging: Show the complete apache config file:
If you really want to see all the complete config settings, there is no existing tool for that. This Stack Overflow page answered this question pretty well: You can use apachectl -S to see the settings of Virtual Host, or apachectl -M to see the loaded modules, but to see all settings, there is no such tool, you will have to go through all the files , starting from familiar yourself with the general structure of the httpd config files.… script …The usage is simple: Run it as
python CombineApacheConfig.py. Since there is no additional parameters given, it will retrieve the default Ubuntu apache config file from/etc/apache2/apache2.confand generate the result complete config file in/tmp/apache2.combined.conf. If your config file is in different location, then give the input file and output file location.Note: Apache server-info page http://127.0.0.1/server-info also provide similar information, but not in the config file format. It is in human readable format. The page works only when it is open from the same computer.
python CombineApacheConfig.py /etc/apache2/httpd.conf /tmp/apache2.combined.conf
–jeroen
| #!/usr/bin/python2.7 | |
| # CombineApacheConfig.py | |
| __author__ = 'ben' | |
| import sys, os, os.path, logging, fnmatch | |
| def Help(): | |
| print("Usage: python CombineApacheConfig.py inputfile[default:/etc/apache2/apache2.conf] outputfile[default:/tmp/apache2.combined.conf") | |
| def InputParameter(): | |
| if len(sys.argv) <> 3: | |
| Help() | |
| return "/etc/apache2/apache2.conf", "/tmp/apache2.combined.conf" | |
| return sys.argv[1], sys.argv[2] | |
| def ProcessMultipleFiles(InputFiles): | |
| Content = '' | |
| LocalFolder = os.path.dirname(InputFiles) | |
| basenamePattern = os.path.basename(InputFiles) | |
| for root, dirs, files in os.walk(LocalFolder): | |
| for filename in fnmatch.filter(files, basenamePattern): | |
| Content += ProcessInput(os.path.join(root, filename)) | |
| return Content | |
| def RemoveExcessiveLinebreak(s): | |
| Length = len(s) | |
| s = s.replace(os.linesep + os.linesep + os.linesep, os.linesep + os.linesep) | |
| NewLength = len(s) | |
| if NewLength < Length: | |
| s = RemoveExcessiveLinebreak(s) | |
| return s | |
| def ProcessInput(InputFile): | |
| Content = '' | |
| if logging.root.isEnabledFor(logging.DEBUG): | |
| Content = '# Start of ' + InputFile + os.linesep | |
| with open(InputFile, 'r') as infile: | |
| for line in infile: | |
| stripline = line.strip(' \t') | |
| if stripline.startswith('#'): | |
| continue | |
| if stripline.lower().startswith('include'): | |
| match = stripline.split() | |
| if len(match) == 2: | |
| IncludeFiles = match[1] | |
| IncludeFiles = IncludeFiles.strip('"') #Inserted according to V's comment. | |
| if not IncludeFiles.startswith('/'): | |
| LocalFolder = os.path.dirname(InputFile) | |
| IncludeFiles = os.path.join(LocalFolder, IncludeFiles) | |
| Content += ProcessMultipleFiles(IncludeFiles) + os.linesep | |
| else: | |
| Content += line # if it is not pattern of 'include(optional) path', then continue. | |
| else: | |
| Content += line | |
| Content = RemoveExcessiveLinebreak(Content) | |
| if logging.root.isEnabledFor(logging.DEBUG): | |
| Content += '# End of ' + InputFile + os.linesep + os.linesep | |
| return Content | |
| if __name__ == "__main__": | |
| logging.basicConfig(level=logging.DEBUG, format='[%(asctime)s][%(levelname)s]:%(message)s') | |
| InputFile, OutputFile = InputParameter() | |
| try: | |
| Content = ProcessInput(InputFile) | |
| except Exception as e: | |
| logging.error("Failed to process " + InputFile, exc_info=True) | |
| exit(1) | |
| try: | |
| with open(OutputFile, 'w') as outfile: | |
| outfile.write(Content) | |
| except Exception as e: | |
| logging.error("Failed to write to " + outfile, exc_info=True) | |
| exit(1) | |
| logging.info("Done writing " + OutputFile) |
Posted in *nix, *nix-tools, Apache2, Development, Linux, openSuSE, Power User, Python, Scripting, Software Development, SuSE Linux | Leave a Comment »
Posted by jpluimers on 2018/03/15
Need to watch these:
A few notes:
$ curl --silent --show-error http://example.org > /dev/null
Segmentation fault (core dumped)
$ curl --silent --show-error http://example.org > /dev/null
I thought I had forgot about the SuSEfirewall2 changes (On my research list: migrate from OpenSuSE SuSEfirewall2 to firewalld) so assumed that was the reason I broke one of my secondaries (which runs on a Raspberry Pi 2):
Mistakes like these are the reason to have secondaries in the first place https://infrastatus.wiert.me and do port-mortems.
Which is kind of odd, as the SuSEfirewall2 didn’t throw any warnings like at this similar one:
This one still works because it is on the firewall in front of the Raspberry Pi 2:
(Screenshots of the above URLs are below).
In fact it was another mistake: I had forgotten to make the DHCP lease static, which resulted in a wrong IP address to be assigned upon reboot, instantly making the firewall rules invalid:
I could have fixed this remotely when I had thought about this.
–jeroen
Posted in *nix, Development, Hardware Development, Linux, openSuSE, Power User, Raspberry Pi, SuSE Linux, Tumbleweed | 3 Comments »
Posted by jpluimers on 2018/02/12
Some notes based on The woods and trees of OpenSuSE on single-board computers – image abbreviations – and getting it installed using OS X « The Wiert Corner – irregular stream of stuff.
I needed to get Ubuntu on an ODROID-C1+ (as it looks like nobody is maintaining a current OpenSuSE for it).
Download either of these (note that “minimal” is different from “mate minimal”; see https://www.youtube.com/watch?v=jOYWx_YToh8) from de.eu.odroid.in/ubuntu_16.04lts:
I installed on a 8 gigabyte SD card that revealed itself as /dev/disk1 using this diskutil command (via osx – List all devices connected, lsblk for Mac OS X – Ask Different [WayBack])
diskutil list
So this wrote the image to SD card in a sudo su - prompt:
targetDevice="disk1"
unxz --keep ubuntu-16.04-minimal-odroid-c1-20160817.img.xz; \
diskutil umount "/dev/${targetDevice}s1"; \
dd bs=1m of="/dev/r${targetDevice}" if=ubuntu-16.04-minimal-odroid-c1-20160817.img; \
sync; \
diskutil list; \
diskutil eject "/dev/${targetDevice}"
Use the default user and password that [WayBack] ODROID Forum • View topic – Ubuntu Minimal User / Password mentions:
odroid login: root
Password: odroid
From there, create a new user and add it to the sudo group (I used visudo to check the correct group for sudoers) :
adduser jeroenp
addgroup jeroenp sudo
And then hook it up to the network and get the IP address:
ifconfig
Now you can ssh into the odroid with user jeroenp and the password assigned to it. You can also perform a sudo su - to get to root level.
First of all, install etckeeper as it’s a life saver:
apt-get install etckeeper
This will install some other packages, but that’s OK; it will end suggesting you to enter email address, name and perform an initial commit:
Initialized empty Git repository in /etc/.git/ *** Please tell me who you are. Run git config --global user.email "you@example.com" git config --global user.name "Your Name" to set your account's default identity. Omit --global to set the identity only in this repository. fatal: unable to auto-detect email address (got 'root@odroid.(none)') etckeeper commit failed; run it by hand
Do that:
cd /etc
git config --global user.email "example@example.org"
git config --global user.name "Example User"
git commit -m "initial commit"
Now perform these steps:
Change root password:
# sudo su -
# passwd
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
Disable etckeeper daily autocommits involves one line in /etc/etckeeper/etckeeper.conf:
-#AVOID_DAILY_AUTOCOMMITS=1
+AVOID_DAILY_AUTOCOMMITS=1
Change the hostname; assuming your new host name is newHostName.
/etc/hosts and replace the old hostname with newHostNamehostnamectl set-hostname newHostName
exec bash
hostname -fBoth the command prompt and the hostname output should show newHostName.
Update/Upgrade:
apt-get update
apt-get upgrade
Fix the cursor in console mode:
Somehow the Odroid C1+ does not support a blinking hardware text cursor.
–jeroen
Posted in *nix, *nix-tools, Development, etckeeper, Hardware Development, Linux, Odroid, openSuSE, Power User, Raspberry Pi, SuSE Linux, Tumbleweed, Ubuntu | Leave a Comment »
Posted by jpluimers on 2018/02/11
The [WayBack] github.com/openSUSE/susefirewall2-to-firewalld is on my research list as right before going on holiday, upgrading broke my firewall configuration (:
Tumbleweed sometimes means living on the bleeding edge (which forces you to learn new things faster), so I knew things like this could be coming.
Related:
From the IRC chat at #opensuse-factory:
[5:25pm] <wiert> Something odd happened today: on an x64 system, I didzypper dist-upgrade, and nowapache2ports80and443are not reachable from the outside any more (only onlocalhost)[5:25pm] <wiert>sysconf_addword /etc/sysconfig/SuSEfirewall2 FW_CONFIGURATIONS_EXT apache2[5:25pm] <wiert>"apache2" already present[5:26pm] <wiert> same foreapache2-ssl[5:27pm] <wiert> sshd on the same line works fine. Apache runs.[5:30pm] Son_Goku joined the chat room.[5:31pm] <wiert> Ah, I see that/etc/sysconfig/SuSEfirewall2.d/services/apache2and/etc/sysconfig/SuSEfirewall2.d/services/apache2-sslgot deleted. Why?[5:32pm] <simonizor> AFAIK, it was replaced byfirewalld[5:33pm] <simonizor> Both useiptablesas a backend, so functionality should be relatively the same[5:34pm] <wiert> Any URLs for migration tips?[5:35pm] <wiert> For now I’ve donesysconf_addword /etc/sysconfig/SuSEfirewall2 FW_SERVICES_EXT_TCP 80[5:35pm] <wiert> andsysconf_addword /etc/sysconfig/SuSEfirewall2 FW_SERVICES_EXT_TCP 443[5:35pm] <wiert> now it “works” but I need to migrate one day.
From a different system when I applied the firewall rules after updating:
# SuSEfirewall2 <38>Mar 12 15:40:13 SuSEfirewall2[20606]: Setting up rules from /etc/sysconfig/SuSEfirewall2 ... <38>Mar 12 15:40:13 SuSEfirewall2[20606]: using default zone 'ext' for interface eth0 iptables-batch v1.6.2: unknown protocol "submission" specified Try `iptables-batch -h' or 'iptables-batch --help' for more information. <35>Mar 12 15:40:17 SuSEfirewall2[20606]: Error: iptables-batch failed, re-running using iptables iptables v1.6.2: unknown protocol "submission" specified Try `iptables -h' or 'iptables --help' for more information. ip6tables-batch v1.6.2: unknown protocol "submission" specified Try `ip6tables-batch -h' or 'ip6tables-batch --help' for more information. <35>Mar 12 15:40:17 SuSEfirewall2[20606]: Error: ip6tables-batch failed, re-running using ip6tables ip6tables v1.6.2: unknown protocol "submission" specified Try `ip6tables -h' or 'ip6tables --help' for more information. <38>Mar 12 15:40:18 SuSEfirewall2[20606]: Firewall rules successfully set
–jeroen
Posted in *nix, openSuSE, Power User, SuSE Linux, Tumbleweed | Leave a Comment »