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/11
So we are all doomed: on debian, beep was an issue leading into a CVE. The fix is an issue too, and also has a CVE.
Source: [WayBack] beep, patch and ed – The Isoblog.
Related:
–jeroen
Posted in *nix, *nix-tools, Debian, Linux, Power User, Security | Leave a Comment »
Posted by jpluimers on 2018/04/10
Many people use it that way. Which means I can put it on an old Raspberry Pi B+ revision 1.2 board (which Wikipedia indicates as the B 1+ in the Specifications table but as Raspberry Pi 1 Model B+ revision 1.2 in the schematics of connectors).
I might consider DietPi as distribution (which is Debian based) as it is even ligher.
See [WayBack] https://www.reddit.com/r/pihole/comments/6h39zr/is_a_raspberry_pi_1_good_enough_for_a_pihole/#divw0i5
One more note: I need to check out which Debian base name (which indicates the version) works best as there seemed to be a dnsmasq issue (not archived because discourse hatesdislikes the WayBack machine and Archive.is):
Like Apple, Android and Delphi, they use name based versions of which I always forget the order of. Luckily the source of the below table gets updated over time [2017 Archive.is, 2018 Archive.is] Debian releases and names – Electric Toolbox Debian releases are named after characters from Toy Story and are frequently referred to with the name rather than the version.:
Version Code name Release date Toy Story character 1.1 Buzz 1996-06-17 Buzz Lightyear 1.2 Rex 1996-12-12 Rex (the T-Rex) 1.3 Bo 1997-06-05 Bo Peep 2.0 Hamm 1998-07-24 Hamm (the pig) 2.1 Slink 1999-03-09 Slinky Dog 2.2 Potato 2000-08-15 Mr Potato Head 3.0 Woody 2002-07-19 Woody the cowboy 3.1 Sarge 2005-06-06 Sarge from the Bucket O’ Soldiers 4.0 Etch 2007-04-08 Etch, the Etch-A-Sketch 5.0 Lenny 2009-02-14 Lenny, the binoculars 6.0 Squeeze 2011-02-06 Squeeze toy aliens 7 Wheezy 2013-05-04 Wheezy the penguin 8 Jessie 2015-04-26 Jessie the cowgirl 9 Stretch 2017-06-17 Rubber octopus from Toy Story 3 10 Buster not yet released Andy’s pet dog 11 Bullseye Not yet released Woody’s horse Sid “unstable” The next door neighbour
Via: [WayBack] Software-update: Pi-hole 3.3.1 – IT Pro – Downloads – Tweakers
–jeroen
Posted in *nix, Debian, Development, Hardware Development, Linux, Power User, Raspberry Pi, Raspbian | 1 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
1https://download.opensuse.org/ports/aarch64/tumbleweed/repo/oss/media.1/products
/ openSUSE 20180322-0https://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
Most important bits of my external infrastructure – page 1
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 »
The Wiert Corner - irregular stream of stuff 