After an upgrade of Friendica, a PHP application using MySQL or MariaDB as a backend I found that while the columns containing the raw textual content had been changed successfully from utf8 to utf8mb4 character sets, some other colums that contained pre-rendered HTML were broken, as they now contained 2 byte sequences turned into HTML entities. [Read more →]
Recently the 18.04.1 point release of Ubuntu came out and I finally started upgrading my desktops & laptops to it from my 16.04 LTS installations. As usual, the upgrade went smoothly, but as can be expected with the switch from Unity to Gnome, the UI has changed dramatically.
Unfortunately, while the indicator-multiload still is getting displayed, changing its settings doesn’t seem to work any more and it is so small that it becomes unreadable. I did find a replacement in the form of the system-monitor widget for the Gnome shell. To install it you need to install the following prerequisites:
To install all the components and uninstall indicator-multiload in a terminal session, use:
sudo apt install chrome-gnome-shell gir1.2-gtop-2.0 gir1.2-networkmanager-1.0 gir1.2-clutter-1.0
sudo apt purge indicator-multiload
Finally you can navigate in your browser to the GNOME Shell Extensions page and enable the widget (or disable it again, if you don’t like it after all).
Some other nitpicks I had with the upgrade to Ubuntu 18.04, while we are on the topic:
I recently locked down all outgoing connections from my DMZ to the internet and now have to open things explicitly in my packet filter. For wordpress I did not find any documentation on that, so here are my findings to be able to update plugins and themes (I don’t care about the RSS feed on the dashboard):
| IP | Port(s) | Description |
|---|---|---|
| 198.143.164.250 | 80 (HTTP) & 443 (HTTPS) | downloads.wordpress.org |
| 198.143.164.251 | 80 (HTTP) & 443 (HTTPS) | api.wordpress.org |
| 192.0.96.247 | 80 (HTTP) & 443 (HTTPS) | api.akismet.com |
| 192.0.96.248 | 80 (HTTP) & 443 (HTTPS) | api.akismet.com |
A customized prompt can serve as a gentle reminder of what system you’re working on — especially helpful if you often find yourself logged into 3-4 systems at a time, window hopping to get several things done at the same time. or if you log in with different accounts. A customized prompt can help if you like to be reminded where you are sitting in the file system or prefer *not* to be reminded where you are in the file system (a full path can take up quite a bit of screen space when you’re seven levels deep into /home/username/apps/docs/…).
All you need to do to define your PS1 variable and save it in your .bashrc or .bash_profile file. As it turns out, however, you have a lot of flexibility on what you put into that prompt.
[…] Set your prompt to the current time. […]
$ PS1="\A> " 20:52> PS1="\t> " 20:50:13>NOTE: The > at the end of these prompts and the blank that follows are optional, but my preference. I like these characters separating my prompts from my commands.
Have trouble remembering what system you’re logged into?
$ PS1='\h> ' boson>[…] If you can’t remember where you are, the w setting will show your path relative to your home directory. The ~, of course, is your home itself.
PS1='\w ' ~When you need some cheering up:
$ PS1=':-) ' :-)When you have amnesia or just want to be reminded what account you’re logged into:
PS1="\u> " lmoore>You can expand this to show both the username and system name like this:
PS1=“\u@\h “
$ PS1="\u@\h> " lmoore@boson>Any of the following can be use din your prompt, though I suspect that few of us will hear the bell even if we use that character string in our prompts.
\a an ASCII bell character (07) \d the date in "Weekday Month Date" format (e.g., "Tue May 26") \e an ASCII escape character (033) \h the hostname up to the first `.' \H the hostname \j the number of jobs currently managed by the shell \l the basename of the shell's terminal device name \n newline \r carriage return \s the name of the shell, the basename of $0 (the portion following the final slash) \t the current time in 24-hour HH:MM:SS format \T the current time in 12-hour HH:MM:SS format \@ the current time in 12-hour am/pm format \u the username of the current user \v the version of bash (e.g., 2.00) \V the release of bash, version + patch level (e.g., 2.00.0) \w the current working directory \W the basename of the current working directory \! the history number of this command \# the command number of this command \$ if the effective UID is 0, a #, otherwise a $ \nnn the character corresponding to the octal number nnn \\ a backslash \[ begin a sequence of non-printing characters, which could be used to embed a terminal control sequence into the prompt \] end a sequence of non-printing characters
Since this is now the third time I ran into this issue and it always mislead me in a completely wrong direction, I’ll finally document it.
So, you are SSH-ing into a remote system (typically Debian or a derivative), then you you install a package or do something else that triggers some access to the locales (UNIX style localization for shell commands etc.) and you see messages similar like this:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LC_TIME = "de_CH.UTF-8",
LC_MONETARY = "de_CH.UTF-8",
LC_ADDRESS = "de_CH.UTF-8",
LC_TELEPHONE = "de_CH.UTF-8",
LC_NAME = "de_CH.UTF-8",
LC_MEASUREMENT = "de_CH.UTF-8",
LC_IDENTIFICATION = "de_CH.UTF-8",
LC_NUMERIC = "de_CH.UTF-8",
LC_PAPER = "de_CH.UTF-8",
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_ALL to default locale: No such file or directory
You might assume that you did not install all the required locales. In the example above I saw these settings of de_CH.UTF-8 on an english only system. So you could generate/install the missing languages i.e. with „dpkg-reconfigure locales„. But note the mentions of „(unset)“ above. Even with all the required locales you still will see these messages.
So, what is the cause of this mess? Nothing is wrong with your server. The actual culprit is a misconfiguration on the host you are running the SSH session from. It has these settings and newer SSH clients provide the comfort functions of exposing your local locale settings to the remote system.
In an ideal scenario this allows you to talk to your server in your native language. Unfortunately some newer linux distributions like Ubuntu starting from 12.04 (it has also been reported on MacOS X) don’t set all of these variables leading to these warnings on system that want these to be set.
TL;DR: The quick solution is to comment the setting in your /etc/ssh/ssh_config file that causes the exposure of these environment variables to your server:
# SendEnv LANG LC_*
Sometimes one sed command is not enough… (via Tobias)
Does anyone knows a way to do this more compact? My sed foo is very limited…
*sed "1,3d" %p | sed '/^$/d' | sed '$d' | base64 -d | gpg --decrypt |%p is a filename in case you wonder.
The 1st * and the last | are needed elsewhere as well. I don’t really like the three seds
It should at least be possible to catenate the sed commands. Does one of these two syntaxes work with your sed version?
sed '1,3d;/^$/d;$d' %p | base64 -d | gpg --decrypt |sed -e ‚1,3d‘ -e’/^$/d‘ -e ‚$d‘ %p | base64 -d | gpg –decrypt |
The best sed documentation IMO is the one from Grymoire. Here are the two methods mentioned above: The poorly documented ; and Multiple commands with -e command
Ein Freund hat mich vor Kurzem um Rat gefragt, da er eine Installation eines Ubuntu-Ablegers für ein Resourcen-armes System zurechtstutzen wollte und ihm dabei die Abhängigkeiten der Pakete in den Weg kamen. Ich arbeite meist mit aptitude auf Debian-basierten Systemen, komme daher mit diesem Werkzeug am besten zurecht um solche Abhängigkeits-Probleme zu lösen und habe ihm einige Tips dazu gesendet: [Read more →]
|
So, I bought myself a Lemote YeeLoong 8089B „notebook“. Well, actually its more a netbook. As I had such god success with Debian on my SGI O2, I wanted to try a more modern MIPS based device. Something that I could actually use for something other than just show of as fancy old school hardware to my buddies. Lemote’s YeeLoong with its Chinese „dragon chip“ Loongson, a reverse engineered, MIPS compatible CPU, provided me with just that thing.
|