Odi's astoundingly incomplete notes
New entriesCode
back | nextTime to switch your Gentoo to Plasma-5
Gentoo has already announced that you should switch from KDE-4 to Plasma-5. Now is a good time to do that. Since yesterday KDE Apps 15.12.3 are marked stable on the amd64 architecture. That means you can upgrade now without adding tons of entries to
To avoid confusion, please note that there is no KDE-5. There is only the Plasma-5 desktop on which KDE apps can run. Plasma is not KDE. KDE-4 apps will still work on Plasma-5. But most newer versions of KDE apps already support Plasma-5, so you get a consistent look-and-feel.
It's actually very nice once you stop this dreadful thing which happens to be baloo.
/etc/portage/package.keywords
.To avoid confusion, please note that there is no KDE-5. There is only the Plasma-5 desktop on which KDE apps can run. Plasma is not KDE. KDE-4 apps will still work on Plasma-5. But most newer versions of KDE apps already support Plasma-5, so you get a consistent look-and-feel.
It's actually very nice once you stop this dreadful thing which happens to be baloo.
Add comment
Grey background in Firefox 46, Thunderbird 52
Firefox 46 and Thunderbird 52 have enabled GTK3 support on Linux. This affects the default background color of web pages that don't specify it. To resolve it, put a custom CSS into your profile folder.
~.mozilla/firefox/*.default/chrome/userContent.css:
~.thunderbird/*.default/chrome/userContent.css:
~.mozilla/firefox/*.default/chrome/userContent.css:
~.thunderbird/*.default/chrome/userContent.css:
body { background-color: white; }GTK3 also affects scrollbar behaviour and the size of form elements.
Thanks mate ! That is a nice tweak !
in software: old != stable
We have now all learned that Debian ships a horribly outdated xscreensaver. We have seen similar things in SuSE, so it's not just Debian. And we have also heard that the package maintainers rather paper over that fact instead of shipping a current version.
Debian has that concept where they bless some random version of a software as "stable". Everything else is automatically declared "unstable". Stable for them means: the package maintainers backport some patches they deem "important" to that old version.
It was also the time of dial-up Internet, static web pages, no mobile phones, POP accounts, news on paper. No forums. Just mailing lists with no easy way to search. You were basically alone with an old book on the C language.
That basically meant, ever growing code bases became a mine field. It was unmaintainable. It started bitrotting everywhere. Litte changes here and there could easily break code in interesting places.
It was the time of Never Touch a Running System. It was the time of everybody being scared of updates. Change freezes over new years'. Extensive testing before some little change could make it into production. Literally months from writing code to deploying it into production! Then if something want wrong, exceptions to that rule to bring a dearly needed fix in quickly.
Huge projects have finally become maintainable. Also structure intrinsic to a language like the package concept of Java, or namespaces in C# help enourmously with organizing large code bases so that you can find your way around. Garbage collection eliminates the need to think too much about memory allocation, which would otherwise be real PITA and a source of many problems in a large system.
This change also leads to greatly increased development speed. The amount of changes that go into projects each day has exploded in the last decade. If you look into a project like OpenStack, the sheer amount of concentrated development power is simply mind boggling.
We have finally come to the conclusion that life is a lot easier if you can get changes into prod as fast as you can, instead of waiting for months. That's the complete opposite of the old paradigm. Yes, that will release bugs into production sometimes. But this way they also get noticed very quickly, and can be fixed speedily. No big deal. Everybody is happy. How many updates of your apps on your smart phone do you get per day? Notice something? Online services like Facebook or Netflix simply don't have maintenance windows. They are permanently online every single millisecond. They release new versions of code several times a day. Nobody even notices.
By the way, have you noticed how people seem to be so much happier about a fixed bug than about a completely new feature? New feature means they need to adapt and learn something new. Fixed bug means they can finally do what they meant to do.
Suddenly those package maintainers find themselves in a situation where they need to decide which patch of possibly hundreds each day to backport. And they face a large code base that they are very unlikely to understand as they are not developers of that software. So how can they actually do this job? Short answer: they generally can't. There are also numerous examples of when package maintainers failed. They thought they could just "fix" something in OpenSSL better than the developers. Surprise, turns out it was a security disaster.
Obviously that concept of keeping an old version forever is not useful anymore. It needs to be replaced. Some Linux distributions like Gentoo have long adopted a rolling release model with no major releases. This fits the new paradigm perfectly. It allows following upstream releases very closely.
Of course simply adopting a rolling release model is no guarantee for uptodate packages either. Also Gentoo has stable/unstable branches (keywords), which means whether integration of the package within the soup is considered complete. Gentoo took 6 years to deem Apache 2.4 "stable".
Also it is insufficient to update only certain packages of a system. Systems must keep current on all packages. For instance only updating apps and keeping an outdated kernel is therefore unsafe.
This has also immediate effects on backward compatibility. It should allow the kernel to break user space from time to time by introducing an incompatible change. Of course this would trigger a cascade of updates to user space. But in a rolling release model this should be a supported scenario. Either adapt to the change or become obsolete!
Debian has that concept where they bless some random version of a software as "stable". Everything else is automatically declared "unstable". Stable for them means: the package maintainers backport some patches they deem "important" to that old version.
Where does that paradigm come from?
From the last century. No, really! There was a point in software history where available system memory became large. So software started becoming larger, simply because you could do more stuff. At the same time the development environments and development processes lacked badly behind that evolution. Can you remember Pair Programming, eXtreme Programming? People were either using Visual C++ 3, or vi to write code. Some even Notepad. There was no infrastructure like static code analysis, continuous integration, basically no unit tests, no coverage analysis. The most you could get was syntax highlighting and CVS.It was also the time of dial-up Internet, static web pages, no mobile phones, POP accounts, news on paper. No forums. Just mailing lists with no easy way to search. You were basically alone with an old book on the C language.
That basically meant, ever growing code bases became a mine field. It was unmaintainable. It started bitrotting everywhere. Litte changes here and there could easily break code in interesting places.
It was the time of Never Touch a Running System. It was the time of everybody being scared of updates. Change freezes over new years'. Extensive testing before some little change could make it into production. Literally months from writing code to deploying it into production! Then if something want wrong, exceptions to that rule to bring a dearly needed fix in quickly.
Fast-forward to today
We have so much infrastructure that crunches the hundreds of thousands of lines of code without us even looking, that points out when something breaks. We have found ways to manage stunning amounts of code without getting lost. We have continuous integration with solid code coverage.Huge projects have finally become maintainable. Also structure intrinsic to a language like the package concept of Java, or namespaces in C# help enourmously with organizing large code bases so that you can find your way around. Garbage collection eliminates the need to think too much about memory allocation, which would otherwise be real PITA and a source of many problems in a large system.
This change also leads to greatly increased development speed. The amount of changes that go into projects each day has exploded in the last decade. If you look into a project like OpenStack, the sheer amount of concentrated development power is simply mind boggling.
Current is the new stable
Today bugs are fixed quickly. Often it takes mere minutes after a bug report until the bug is fixed in the code. And mere hours or days until it goes into production.We have finally come to the conclusion that life is a lot easier if you can get changes into prod as fast as you can, instead of waiting for months. That's the complete opposite of the old paradigm. Yes, that will release bugs into production sometimes. But this way they also get noticed very quickly, and can be fixed speedily. No big deal. Everybody is happy. How many updates of your apps on your smart phone do you get per day? Notice something? Online services like Facebook or Netflix simply don't have maintenance windows. They are permanently online every single millisecond. They release new versions of code several times a day. Nobody even notices.
By the way, have you noticed how people seem to be so much happier about a fixed bug than about a completely new feature? New feature means they need to adapt and learn something new. Fixed bug means they can finally do what they meant to do.
Suddenly those package maintainers find themselves in a situation where they need to decide which patch of possibly hundreds each day to backport. And they face a large code base that they are very unlikely to understand as they are not developers of that software. So how can they actually do this job? Short answer: they generally can't. There are also numerous examples of when package maintainers failed. They thought they could just "fix" something in OpenSSL better than the developers. Surprise, turns out it was a security disaster.
When software dies
Also software is not maintained forever. Sometimes development simply stalls. Because everybody left the project and had children. Or one of various other reasons. That's the time when also users of that software need to find something else. They will need to stop using it. Software is not alone. It runs embedded in a soup of other software. Sooner or later it will become incompatible with the rest of that soup and actually stop working anyway. Or security issues that were found pile up and make this piece of software a dangerous item.Obviously that concept of keeping an old version forever is not useful anymore. It needs to be replaced. Some Linux distributions like Gentoo have long adopted a rolling release model with no major releases. This fits the new paradigm perfectly. It allows following upstream releases very closely.
Of course simply adopting a rolling release model is no guarantee for uptodate packages either. Also Gentoo has stable/unstable branches (keywords), which means whether integration of the package within the soup is considered complete. Gentoo took 6 years to deem Apache 2.4 "stable".
Who doesn't move dies
All the above has interesting consequences if software is never updated. Such as in embedded systems. Such systems become dangerous items with time and must be disposed of.Also it is insufficient to update only certain packages of a system. Systems must keep current on all packages. For instance only updating apps and keeping an outdated kernel is therefore unsafe.
This has also immediate effects on backward compatibility. It should allow the kernel to break user space from time to time by introducing an incompatible change. Of course this would trigger a cascade of updates to user space. But in a rolling release model this should be a supported scenario. Either adapt to the change or become obsolete!
KDE clear baloo db
KDE Plasma 5 has this nice launcher that lets you simply start typing and will display search results. Unfortunately they are completely useless. Because they come from Baloo.
The first thing Baloo does is read your whole freaking hard drive and create a full text index from it. Well thanks. I never asked for that. Guess how long that takes for today's disk sizes. And guess how interesting results are from tons of Java API Doc that happens to be installed somewhere deep in a forgotten corner of the file system.
Well, you think, let's just clear the index and let it only index what seems to be useful. Then to your surprise the settings dialog provides no such controls to clear the index. There is a CLI tool called
OK disable baloo via CLI:
or tell Baloo's config file what you really want.
Using strace I was able to find where baloo stores its index:
See also the checkbox 'Expand search to bookmarks, files and emails' in Application Laucher Settings.
The first thing Baloo does is read your whole freaking hard drive and create a full text index from it. Well thanks. I never asked for that. Guess how long that takes for today's disk sizes. And guess how interesting results are from tons of Java API Doc that happens to be installed somewhere deep in a forgotten corner of the file system.
Well, you think, let's just clear the index and let it only index what seems to be useful. Then to your surprise the settings dialog provides no such controls to clear the index. There is a CLI tool called
balooctl
that even has a clear
command. But that seems to accept only individual full path names.OK disable baloo via CLI:
balooctl disable
or tell Baloo's config file what you really want.
Using strace I was able to find where baloo stores its index:
~/.local/share/baloo
. Simply nuke this unfortunate thing out of existance.See also the checkbox 'Expand search to bookmarks, files and emails' in Application Laucher Settings.
Thank you! That helped me ignore the nagging feeling that I might be throwing away something important.
Second step: echo "[General]\nonly basic indexing=true" >> ~/.config/baloofilerc
Second step: echo "[General]\nonly basic indexing=true" >> ~/.config/baloofilerc
Thanks! That was useful. My Index file was grown to 11GB! Not I have done "balooctl disable" and I can forget about this thing ;)
Thank you. The file indexer should be off by default, especially for content.
You can do balooctl purge to clear the index
Ancient Apache Version on SuSE EL 11
How can it be that such a modern Linux distribution ships such an outdated Apache version?!? Apache 2.4 is availably since 4 years. Are they crazy?
Consequence? Customer's brave admin compiles Apache 2.4 manually. Of course he will then walk away and forget about that box that's completely exposed to the Internet. Very bright idea.
# cat /etc/SuSE-release SUSE Linux Enterprise Server 11 (x86_64) VERSION = 11 PATCHLEVEL = 3 # httpd2 -V | grep version Server version: Apache/2.2.12 (Linux/SUSE)If they have applied additional patches, then that is totally unclear from the version number.
Consequence? Customer's brave admin compiles Apache 2.4 manually. Of course he will then walk away and forget about that box that's completely exposed to the Internet. Very bright idea.
Installing Oracle 12c on x86_64 Gentoo
Installing Oracle 12c on an uptodate Gentoo system is no problem at all and a lot easier than installing 11g.
emerge the following additional packages:
emerge the following additional packages:
- ksh (93.20140625 works fine)
- rpm
- xdpyinfo
- libXi
- libXtst
- libXau
- libXi
- libaio
- sysstat
- elfutils
/dev/shm
mount options need to be default and the size needs to be set to accomodate your SGA. NB that more shm is required than the size of your SGA. This seems to be due to Oracle bugs. The required additional space can be a lot. To be safe, just set it to all available memory:/etc/fstab
:shm /dev/shm tmpfs defaults,size=64g 0 0Then:
mount -o remount,defaults,size=64g /dev/shm
/etc/sysctl.conf: Always overcommit seems to be the only working solution with dozens of GB SGA.
# there is no swap really
vm.swappiness=0
# 0: default overcommit
# 1: always overcommit
# 2: never overcommit. max = swap + ratio% * RAM
vm.overcommit_memory=1
# commit limit = (swap + ratio% * RAM)
vm.overcommit_ratio=100
Then sysctl -p
If remote installing:
- /etc/ssh/sshd_config: X11Forwarding yes
- use
ssh -Y user@host
./runInstaller
Disable password expiryUltimate usability test: change your SMTP port
Ever wonder how much the vendor of your mail client cares about usability? Then try and change the SMTP port.
Outlook is horrible. Hidden behind a cascade of dialogs and inside a wizard.
Apple Mail is even worse. Note the hidden button inside a drop down (yuck!).
Thunderbird just requires 3 clicks.
All of them have in common that the setting is separated from your incoming (IMAP, POP3) account settings. While technically correct, this is not where I would look first.
Outlook is horrible. Hidden behind a cascade of dialogs and inside a wizard.
Apple Mail is even worse. Note the hidden button inside a drop down (yuck!).
Thunderbird just requires 3 clicks.
All of them have in common that the setting is separated from your incoming (IMAP, POP3) account settings. While technically correct, this is not where I would look first.
qemu: SHA1 hash support is required for websockets
That error message from qemu wants to tell you that you need to compile it with gnutls support enabled. Set the
gnutls
USE flag on Gentoo.Allowing normal users to restart Apache using polkit
Allow an ordinary unprivileged user to restart a system service like Apache is a frequent requirement in operations. I enounter this on a daily basis when the customer (owner of the machine) asks me (manufacturer of the application) to configure Apache for our application or to troubleshoot an issue. Of course they don't just want to give me complete root access. So what do they do? Usually it's just
I am very uneasy with passing user controlled arguments to shell scripts. The whole command should be wrapped into a script that does its job without any arguments.
And in a second step you could do it also via polkit. As that's a bit verbose, here is how.
1. Create the program to run. Here we simply execute the command to restart Apache.
2. Create the policy for pkexec. Customize the action ID (freely chose the part after pkexec).
3. Define a rule to which user this applies.
polkit.addRule(function(action, subject) {
if (action.id == "org.freedesktop.policykit.pkexec.httpd-restart" &&
subject.user == "john.doe") {
return polkit.Result.YES;
}
});
4. Now user john.doe can safely execute this without entering a password:
pkexec is an suid binary. It performs checks via polkit and then executes the passed command. It essentially works the same as sudo (which is also an suid binary). The same precautions to running a binary as root apply: don't let users execute random binaries as root if those binaries can also do their job as a normal user.
That means: don't run an editor (vim) as root just to edit a file that happens to be owned by root. Editing doesn't require root privileges. Neither does file access. Let them run their favourite editor themselves and give them access to the file with permissions/ACLs. See man setfacl.
sudo /etc/init.d/httpd restart
.I am very uneasy with passing user controlled arguments to shell scripts. The whole command should be wrapped into a script that does its job without any arguments.
And in a second step you could do it also via polkit. As that's a bit verbose, here is how.
1. Create the program to run. Here we simply execute the command to restart Apache.
/usr/local/sbin/httpd-restart
:
#!/bin/sh exec /etc/init.d/httpd restart
2. Create the policy for pkexec. Customize the action ID (freely chose the part after pkexec).
/usr/share/polkit-1/actions/httpd-restart.policy
:
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE policyconfig PUBLIC "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN" "http://www.freedesktop.org/standards/PolicyKit/1.0/policyconfig.dtd"> <policyconfig> <vendor>Odi</vendor> <vendor_url>http://www.odi.ch/</vendor_url> <icon_name>computer</icon_name> <action id="org.freedesktop.policykit.pkexec.httpd-restart"> <description>Restart Apache</description> <message>Authentication is required to restart Apache</message> <defaults> <allow_inactive>no</allow_inactive> <allow_active>no</allow_active> </defaults> <annotate key="org.freedesktop.policykit.exec.path">/usr/local/sbin/httpd-restart</annotate> </action> </policyconfig>
3. Define a rule to which user this applies.
/etc/polkit-1/rules.d/httpd-restart.rules
:polkit.addRule(function(action, subject) {
if (action.id == "org.freedesktop.policykit.pkexec.httpd-restart" &&
subject.user == "john.doe") {
return polkit.Result.YES;
}
});
4. Now user john.doe can safely execute this without entering a password:
pkexec /usr/local/sbin/httpd-restartSecurity notes:
pkexec is an suid binary. It performs checks via polkit and then executes the passed command. It essentially works the same as sudo (which is also an suid binary). The same precautions to running a binary as root apply: don't let users execute random binaries as root if those binaries can also do their job as a normal user.
That means: don't run an editor (vim) as root just to edit a file that happens to be owned by root. Editing doesn't require root privileges. Neither does file access. Let them run their favourite editor themselves and give them access to the file with permissions/ACLs. See man setfacl.
sudo is a complete failure
Today it was about the 10th time that a customer gave me permissions to edit a config file by allowing me to
Of course there is also the lazy admin that doesn't care at all and tells you to use
Apparently many system admins think that sudo has something to do with security. And obviously they have not the slightest concept of what it actually does. What it actually does is: it is an binary with the
As we all know: executing random programs as root is a very bad idea in the first place. Doing that through sudo isn't any safer.
Apple and Ubuntu use it to obfuscate the fact that they basically run everything with the possibility to obtain root privileges by merely knowing the current user's password (if any at all).
sudo should be removed from computers. It is security theater and does more harm than good by tricking admins into running completely insecure software as root.
If you need to give people access to config files, then use file system permissions (hello we have had ACLs for many years now!). Yes I know by letting john.doe edit Apache config he can also easily get root. But that's not the point here. The point is abuse of sudo to work around file system permissions.
back
|
next
sudo vi
. If you don't see the problem, then read why this gives you full root access.$ sudo -l Matching Defaults entries for xxx on this host: always_set_home, env_reset, env_keep="LANG LC_ADDRESS LC_CTYPE LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE LC_TIME LC_ALL LANGUAGE LINGUAS XDG_SESSION_COOKIE", targetpw, syslog=auth, env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY PATH" User xxx may run the following commands on this host: (root) NOPASSWD: /usr/bin/vi /etc/apache2/*, (root) /usr/bin/vi /etc/apache2/conf.d/*, (root) /usr/bin/less /var/log/apache2/*, (root) /etc/init.d/httpdOMG wildcards! And I also control PATH! There are so many possibilities to get full root access from this misconfiguration, I don't even bother to list them here.
Of course there is also the lazy admin that doesn't care at all and tells you to use
sudo su
, which not only gives you a full root shell in the first place but also leaves you with a polluted environment.Apparently many system admins think that sudo has something to do with security. And obviously they have not the slightest concept of what it actually does. What it actually does is: it is an binary with the
suid
bit set (always runs as root), that simply checks rules in the /etc/sudoers
and then executes the passed command verbatim as a root process.As we all know: executing random programs as root is a very bad idea in the first place. Doing that through sudo isn't any safer.
Apple and Ubuntu use it to obfuscate the fact that they basically run everything with the possibility to obtain root privileges by merely knowing the current user's password (if any at all).
sudo should be removed from computers. It is security theater and does more harm than good by tricking admins into running completely insecure software as root.
If you need to give people access to config files, then use file system permissions (hello we have had ACLs for many years now!). Yes I know by letting john.doe edit Apache config he can also easily get root. But that's not the point here. The point is abuse of sudo to work around file system permissions.
# allow john.doe to edit a single file setfacl -m 'u:john.doe:rw' /etc/apache2/httpd.conf # allow john.doe to edit all apache config setfacl -m 'u:john.doe:rwx' /etc/apache2/conf.d setfacl -m 'u:john.doe:rw' /etc/apache2/conf.d/*.confIf you are scared to set the suid bit on the executable itself, then you shouldn't run it via sudo either.