Problem: Apache needs very long to start on a virtual server running on a KVM/QEMU virtual maschine.
Solution: Apache needs a RNG (random number generator) for startup, probably because of TLS. A pure virtual maschine has no RNG device per default. If you add an RNG device to the virtual maschine configuration, apache startup is lightening fast.
<address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
Versions: tested with libvirt 3.0.0, qemu-kvm 2.8 on devuan 9
Unix file systems like ext3/4 can store files which are partly empty more efficiently by not storing blocks with all zeros. These files are called sparse files. When reading these files every things works as normal but “all zero” blocks don’t wast space on the drive.
This can be useful for different application. For example a database can make a big file for random access, without using the space on the drive. The actual size on the disk grows with every used block. Another example are raw disk images for virtualization like KVM. You can make a 10GB disk image which uses almost no space, and grows only when used.
Usefull sysadmin commands:
"du -h --apparent-size FILE" shows the full file size including sparse areas
"du -h FILE" shows the actual space used on the file system
"ls -lh FILE" show the full file size
"ls -sh FILE" shows the actual space used on the file system
"fallocate -d FILE" make a file sparse, which means "digs holes" for "all zero" blocks
"rsync -S ..." the -S option makes rsync sparse file aware and produces sparse files at the receiver
"truncate -s 1G FILE" makes a sparse file with 1GB that uses no file system space
Problem: The remote console feature of a Dell R710 server does not open with an Linux client with errors like these:
Connection failed, Unsigned Java Applett, etc
Solution: I had to change three things:
in /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/security/java.security I had to change to these lines:
# jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024, DSA keySize < 1024
jdk.jar.disabledAlgorithms=MD2, RSA keySize < 1024, DSA keySize < 1024
#jdk.tls.disabledAlgorithms=SSLv3, RC4, DES, MD5withRSA, DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL
jdk.tls.disabledAlgorithms=RC4, DES, MD5withRSA, DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL
And in ~/.java/deployment/deployment.properties I changed these lines:
And there is still a small bug: cursor keys won’t work, but numpad cursor keys do.
Problem: Akamai is showing very high edge traffic volume, but other sources of accounting show less traffic, and Akamai is billing this high volume!
Discussion: I activated log shipping to compare the volume of the shipped data, to the reported volume by Akamai. The difference was +66% in the Akamai volume. Support was not help full. So I investigated deeper and found out, that the ratio for images was much lower and much higher for css/html/js files. So I checked compression.
Even though the origin servers can do compression, they did not use compression with Akamai. The reason for this was that IIS disables compression when it receives a “Via:” header, because there is some old HTTP spec that says “you should disable compression, when you get the request trough a proxy, because the proxy might not be capable of compression.”
You may say: I don’t care about uncompressed data from the origin because you have a 99% cache rate. I can handle 1% of traffic to be uncompressed.
But! When Akamai receives an object uncompressed, it counts and bills every download of this object in uncompressed size, even though all the requests to the client edge are compressed.
A small calculation: If you publish some css/js/html file with 5 MegaBytes, 1 million times per day, Akamai is charging you 5TeraBytes of traffic. But in reality they ship only about 625 GigaBytes to the users with an average of 1/8 compression for these kind of files !
This means you can reduce about 86% of your Akamai bill, for good compressible files.
Solution: Make sure that your origin servers always sends compressed data to Akamai by ignoring or removing the “Via:” header. And check this repeatedly because Akamai may add other headers that disable compression on the origin side.
Ref: Origin impact is explained here: https://community.akamai.com/customers/s/article/Beware-the-Via-header-and-its-bandwidth-impact-on-your-origin?language=en_US
Billing is explained here: https://community.akamai.com/customers/s/article/Reporting-of-compressed-content-on-Akamai-1386938153725
We will show and bill the uncompressed content size in the following circumstances:
– The origin (including NetStorage) sent the object uncompressed
– An edge server receives the object compressed from the origin, or a peer edge server, but had to uncompress it because of an internal process, including, but not limited to:
Edge Side Include (ESI)
– The client does not support compression (the request did not include an Accept-Encoding: gzip header)
Problem: Some flac players refuse to play some flac files, and even tools like an old ffmpeg can’t handle some flac files
Solution: These flac files might have id3v2 tags which they realy should not, because flac uses vorbis style tags and not id3. Remove those id3v2 tags with this command:
> id3v2 --delete-all song.flac
This removes the id3v2 tags from the flac file in place
Discussion: Those flac files were made with EAC. In the encoder settings “Add ID3 Tags” was checked, and EAC added ID3 tags even though flac files don’t need and must not have ID3 tags. If you like to know, whether your flac files have these false ID3 tags your can run “id3v2 -l song.flac” or look into the files with hexdump.
hexdump -C song-with-id3.flac | head
00000000 49 44 33 03 00 00 00 06 44 0b 54 49 54 32 00 00 |ID3.....D.TIT2..|
00000010 00 27 00 00 01 ff fe 54 00 68 00 65 00 20 00 46 |.'.....T.h.e. .F|
00000020 00 69 00 72 00 65 00 20 00 54 00 68 00 69 00 73 |.i.r.e. .T.h.i.s|
00000030 00 20 00 54 00 69 00 6d 00 65 00 54 50 45 31 00 |. .T.i.m.e.TPE1.|
hexdump -C song-without-id3.flac | head
00000000 66 4c 61 43 00 00 00 22 10 00 10 00 00 00 10 00 |fLaC..."........|
00000010 2b 54 0a c4 42 f0 00 bf 39 4c 3d e0 59 d1 58 72 |+T..B...9L=.Y.Xr|
00000020 49 b7 d4 56 99 08 c4 ae 45 b5 03 00 02 0a 00 00 |I..V....E.......|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 10 00 |................|
Correct flac files start with “fLaC” and not “ID3”
Version: EAC “Exact Audio Copy” Sept. 2019
If you like to block network access for certain users on a linux box it’s as simple as that:
/sbin/iptables -I OUTPUT -m owner --uid-ower <USERNAME> -j DROP
Username might also be the username of a running service.
Problem: current Chrome browsers cut URl parts and hide the correct URL. https://www.derstandard.at/ is shown as derstandard.at. This is simply wrong from the technical point of view. And it might even be dangerous for some URLs form a security standpoint.
Solution: there is an option to disable this bug:
Update: oogle ropped his ption. The new sollution starting with 79 is this startup paramter:
Update 2: “They are evil now” did it again. URLs are broken again. The option of the day for Chrom80 to repair the URLs is:
Why does Google insist on breaking the URL scheme ? What’s behind this ?
Update 3: New method to work around the Chrome URL bug for version 83:
Enable the setting: chrome://flags/#omnibox-context-menu-show-full-urls
then right click in the location input field and activate “Alway show full URLs”
Problem: when debian goes from “testing” to “stable” to “oldstable” the package sources change. eg. jessie-updates are remove, same happened to jessie-backports
The current file /etc/apt/sources.list for jessie (currently oldstable) could look like this
deb http://ftp.debian.org/debian/ jessie main contrib non-free
deb http://security.debian.org/ jessie/updates main contrib non-free
If you want to configure WLAN settings on a Linux machine statically you can use the normal /etc/network/interfaces configuration method of Debian. For WPA-PSK you can use this 3 steps:
Install the “wpasupplicant” package
Generate a psk line with “wpa_passphrase” and copy the hex string after “psk=”
root@server:~# wpa_passphrase WLANNAME
# reading passphrase from stdin
Add some lines to /etc/network/interfaces using this hex string
iface wlan0 inet dhcp
The line “wpa-scan-ssid 1” allows to use hidden WLAN that are not broadcasted. With “metric 4” you can make WLAN less preferred if there is a second LAN connection that should be preferred (default is “metric 1”).
Akamai just works, … most of the time. But sometimes you have to check what’s going on, and Akamai gives you a handy tool for this.
There is an HTTP request header that tells Akamai to respond with some internal information.
Pragma: akamai-x-cache-on, akamai-x-cache-remote-on, akamai-x-check-cacheable, akamai-x-get-cache-key, akamai-x-get-ssl-client-session-id, akamai-x-get-true-cache-key, akamai-x-get-request-id
With this request header Akamai includes this in the response header
X-Cache: TCP_MISS from a84-53-161-127.deploy.akamaitechnologies.com (AkamaiGHost/188.8.131.52.1-25325260) (-)
X-Cache-Key: S/L/16382/612780/0s/www.yourdomain.de/ cid=what_TOKEN=dings_
X-Cache-Key-Extended-Internal-Use-Only: S/L/16382/612780/0s/www.yourdomain.de/ vcd=1948 cid=what_TOKEN=dings_
X-True-Cache-Key: /L/www.yourdomain.de/ vcd=1948 cid=what_TOKEN=dings_
Some important parts:
- TCP_MISS shows that Akamai didn’t use it’s cache for this request, but the origin
- X-Cache-Key shows what Akamai used to reference the cache position. In this case the url was http://www.yourdomain.de/?what and a cookie named TOKEN was included in the cacheID (“cid=…”)