Scott was trying to move some backup files from /a/path/to/backup to /a/path/to-a-different/backup — he’s using Dolphin & has a tab open to each of the folders in question. He chown’d /a/path to his account, chmod’d /a/path so user can read and write. But using the copy/paste option … nothing happens.
I came across a few old (and closed) bugs that seemed to produce errors in this same situation — but the reporters were able to perform their copy/move operations when they used the same tab instead of having one folder open in each tab. It worked … inexplicable, but we have success!
We picked up a really nice color laser printer — a Dell 1350CN. It was really easy to add it to my Windows computer — download driver, install, voila there’s a printer. We found instructions for using a Xerox Phaser 6000 driver. It worked perfectly on Scott’s old laptop, but we weren’t able to install the RPM on his new laptop — it insisted that a dependency wasn’t found: libstdc++.so.6 CXXABI_1.3.1
Except, checking the file, CXXABI_1.3.1 is absolutely in there:
2022-09-17 13:04:19 [lisa@fc36 ~/]# strings /usr/lib64/libstdc++.so.6 | grep CXXABI
We’ve tried using the foo2hbpl package with the Dell 1355 driver to no avail. It would install, but we weren’t able to print. So we returned to the Xerox package.
Turns out the driver package we were trying to use is a 32-bit driver (even though the download says 32 and 64 bit). From a 32-bit perspective, we really didn’t have libstdc++ — a quick dnf install libstdc++.i686 installed the library along with some friends.
Xerox’s rpm installed without error … but, attempting to print, just yielded an error saying that the filter failed. I had Scott use ldd to test one of the filters (any of the files within /usr/lib/cups/filter/Xerox_Phaser_6000_6010/ — it indicated the “libcups.so.2” could not be found. We also needed to install the 32-bit cups-libs.i686 package. Finally, he’s able to print from Fedora 36 to the Dell 1350cn!
You can use dmidecode to list all sorts of information about the system — there is a list of device types that you can use with the “-t” option
5 Memory Controller
6 Memory Module
8 Port Connector
9 System Slots
10 On Board Devices
11 OEM Strings
12 System Configuration Options
13 BIOS Language
14 Group Associations
15 System Event Log
16 Physical Memory Array
17 Memory Device
18 32-bit Memory Error
19 Memory Array Mapped Address
20 Memory Device Mapped Address
21 Built-in Pointing Device
22 Portable Battery
23 System Reset
24 Hardware Security
25 System Power Controls
26 Voltage Probe
27 Cooling Device
28 Temperature Probe
29 Electrical Current Probe
30 Out-of-band Remote Access
31 Boot Integrity Services
32 System Boot
33 64-bit Memory Error
34 Management Device
35 Management Device Component
36 Management Device Threshold Data
37 Memory Channel
38 IPMI Device
39 Power Supply
40 Additional Information
41 Onboard Devices Extended Information
42 Management Controller Host Interface
[lisa@fedora ~/]# dmidecode -t 9
Handle 0x0024, DMI type 9, 17 bytes
System Slot Information
Type: 32-bit PCI
Current Usage: In Use
3.3 V is provided
Opening is shared
PME signal is supported
Bus Address: 0000:0a:02.0
The “Bus Address” value corresponds to information from lspci:
[lisa@fedora ~/]# lspci | grep “0a:02.0”
0a:02.0 Multimedia video controller: Conexant Systems, Inc. CX23418 Single-Chip MPEG-2 Encoder with Integrated Analog Video/Broadcast Audio Decoder
To view the scripts being executed by an RPM, use rpm -qp --scripts packagename
Beyond basic stuff like “dnf install somepackage” or downloading an rpm and using “dnf install my.package.rpm”, this is a running list of useful dnf commands.
List installed packages (similar to rpm -qa):
dnf list installed
List packages with updates available:
Update everything but the kernel:
dnf update -x kernel*
Find package that provides something:
[lisa@rhel1 ~/]# dnf whatprovides cdrskin
Last metadata expiration check: 2:35:57 ago on Fri 12 Aug 2022 11:37:43 AM EDT.
cdrskin-1.5.2-2.fc32.x86_64 : Limited cdrecord compatibility wrapper to ease migration to libburn
Repo : fedora
Provide : cdrskin = 1.5.2-2.fc32
cdrskin-1.5.4-2.fc32.x86_64 : Limited cdrecord compatibility wrapper to ease migration to libburn
Repo : updates
Provide : cdrskin = 1.5.4-2.fc32
Package info, including version
[lisa@rhel1 ~/]# dnf info sendmail
Last metadata expiration check: 2:37:19 ago on Fri 12 Aug 2022 11:37:43 AM EDT.
Name : sendmail
Version : 8.15.2
Release : 43.fc32
Architecture : x86_64
Size : 730 k
Source : sendmail-8.15.2-43.fc32.src.rpm
Repository : fedora
Summary : A widely used Mail Transport Agent (MTA)
URL : http://www.sendmail.org/
License : Sendmail
Description : The Sendmail program is a very widely used Mail Transport Agent (MTA).
: MTAs send mail from one machine to another. Sendmail is not a client
: program, which you use to read your email. Sendmail is a
: behind-the-scenes program which actually moves your email over
: networks or the Internet to where you want it to go.
: If you ever need to reconfigure Sendmail, you will also need to have
: the sendmail-cf package installed. If you need documentation on
: Sendmail, you can install the sendmail-doc package.
[lisa@rhel1 ~/]# dnf history
ID | Command line | Date and time | Action(s) | Altered
102 | remove liberation-fonts | 2021-11-28 18:44 | Removed | 3
101 | remove chromedriver | 2021-11-28 18:44 | Removed | 2
100 | remove google-chrome-stable | 2021-11-28 18:44 | Removed | 1 < 99 | install liberation-fonts | 2021-11-28 18:42 | Install | 1 >
98 | install chromedriver | 2021-11-28 18:38 | Install | 2
97 | remove mediainfo | 2021-11-16 13:31 | Removed | 4
96 | install mediainfo | 2021-11-16 13:29 | Install | 4
Which brings up an interesting command — you can undo a history step instead of trying to uninstall the list of things you just installed.
dnf history undo 98 -y
We needed to console into some Cisco access points — RJ45 to USB to plug into the device console port and the laptop’s USB port? Check! OK … now what? Turns out you can use the screen command as a terminal emulator. The basic syntax is screen <port> <baud rate> — since the documentation said to use 9600 baud and the access point showed up on /dev/ttyUSB0, this means running:
screen /dev/ttyUSB0 9600
More completely, screen <port> <baud rate>,<7 or 8 bits per byte>,<enable or disable sending flow control>,<enable or disable rcving flow control>,<keep or clear the eight bit in each byte>
screen /dev/ttyUSB0 9600,cs8,ixon,ixoff,istrip
- or -
screen /dev/ttyUSB0 9600,cs7,-ixon,-ixoff,-istrip
While using telnet to connect to a host:port is a quick way to verify connectivity … it only works for tcp ports. There’s no udp telnet. But there are a few ways to verify a port is open and available to you …
nmap with -sU will show the port as open or closed
nc will send a packet
I’m using IPv6 on a server — the server wasn’t using NetworkManagement, so I’ve configured it directly in the network script file.
After restarting the network (systemctl restart network), I was able to ping other IPv6 addressed equipment.
We occasionally get alerted that our /var volume is over 80% full … which generally means /var/log has a lot of data, some of which is really useful and some of it not so useful. The application-specific log files already have the shortest retention period that is reasonable (and logs that are rotated out are compressed). Similarly, the system log files rotated through logrotate.conf and logrotate.d/* have been configured with reasonable retention.
Using du -sh /var/log/ showed the /var/log/sa folder took half a gig of space.
This is the daily output from sar (a “daily summary of process accounting” cron’d up with /etc/cron.d/sysstat). This content doesn’t get rotated out with the expected logrotation configuration. It’s got a special configuration at /etc/sysconfig/sysstat — changing the number of days (or, in my case, compressing some of the older files) is a quick way to reduce the amount of space the sar output files consume).
There is a great deal of documentation available for building Gerbera from source on a variety of Linux flavors. Unfortunately, Fedora isn’t one of those (and the package names don’t exactly match up to let you replace “apt-get” with “yum” and be done). So I am quickly documenting the process we followed to build Gerbera from source.
The Fedora build of Gerbera has the binaries in /usr/bin and the manual build places the gerbera binary in /usr/local/bin — the build updates the unit file to reflect this change, but this means you want to back up any customizations you’ve made to the unit file before running “make install”.
You need the build system — cmake, g++, etc and the devel packages from the following table as required by your build options
||Build from source (if needed)
||I was only able to locate this as a source, not available from Fedora repos
||Not required on *BSD
||XML file and data support
||Fast string formatting
||Alternate database storage
||Enables web services
||Audio tag support
||File type detection
||MKV metadata required for MKV
||MKV metadata required for MKV
||JPEG Exif metadata
||Exif, IPTC, XMP metadata
||Generate video thumbnails
||Efficient file monitoring
Then follow the generalized instructions — cd into the folder where you want to run the build and run (customizing the cmake line as you wish):
git clone https://github.com/gerbera/gerbera.git
cmake ../gerbera -DWITH_MAGIC=1 -DWITH_MYSQL=1 -DWITH_CURL=1 -DWITH_INOTIFY=1 -DWITH_JS=1 -DWITH_TAGLIB=1 -DWITH_AVCODEC=1 -DWITH_FFMPEGTHUMBNAILER=0 -DWITH_EXIF=1 -DWITH_EXIV2=1 -DWITH_SYSTEMD=1 -DWITH_LASTFM=0 -DWITH_DEBUG=1
sudo make install
As with the Gerbera binary, the Fedora build places the web content in /usr/share/gerbera and the manual build places the web content into /usr/local/share/gerbera — yes, you can change the paths in the build, and I’m sure you can clue Gerbera into the new web file location. I opted for the quick/easy/lazy solution of running
mv /usr/share/gerbera /usr/share/gerbera/old
ln -s /usr/local/share/gerbera /usr/share/
To symlink the location my config thinks the web components should be located to the new files.
On the first start of Gerbera, SQL scripts may be run to update the database — don’t stop or kill the service during this process there’s no checkpoint restart of the upgrade process. We backed up /etc/gerbera/gerbera.db prior to starting our Gerbera installation. We’ve also wiped the database files to start from scratch and test changes that impacted how items are ingested into the database.