Uploading a Snapshot to a Fresh Home Assistant OS Instance
Hi!
After finding that my previously running Home Assistant OS instance was no longer working let alone starting properly, I decided to wipe it and simply install from a fresh image today. In order to pick up where I left off, I wanted to restore from a snapshot that I made a short while ago.
Out of the box, Home Assistant OS does not seem to come with any way to upload snapshots (or any other kind of files) onto the instance. Usually, this would not be a problem, because I had previously used the Samba share add-on from the official add-on repository, but since updating it to the new repository website, the Samba share add-on seems to have disappeared.
My first alternate approach using the SSH access did not work either, as I could not use SFTP because it is not effectively using proper SSH/SFTP but an intermediate wrapper for the Home Assistant console.
The quickest way I found that had minimal impact on the system in terms of creating a mess was to use Docker and download my latest snapshot from a web server hosted somewhere else via cURL. In this case I was using a self-hosted Nextcloud instance with a shared file link, but your mileage may of course vary.
Prerequisites / Assumptions
- You are using the Home Assistant OS official image on a device in headless mode, so you have a minimal system without neat tools like curl or wget pre-installed.
- You have uploaded the snapshot file to a web server that is accessible from the Home Assistant OS system (in terms of network connectivity).
Steps
- Enable SSH access by following the official documentation on how to enable SSH access to the host.
- Update from 2020-05-21: They seem to have restructured the documentation and the original instructions are no longer on that page. It used to say:
Use a USB drive formatted with FAT, ext4, or NTFS and name it CONFIG (case sensitive). Create an "authorized_keys" file (no extension) containing your public key, and place it in the root of the USB drive. File needs to be ANSI encoded (not UTF-8) and must have Unix line ends (LF), not Windows (CR LF). [...] From the UI, navigate to the Supervisor system page and choose "Import from USB". You can now access your device as root over SSH on port 22222. Alternatively, the file will be imported from the USB when the Home Assistant OS device is rebooted.
- Update from 2020-05-21: They seem to have restructured the documentation and the original instructions are no longer on that page. It used to say:
- Log into the Home Assistance OS instance via SSH.
- Type the command "login" to enter the actual shell.
- Use the following command to download the snapshot file:
docker run --rm curlimages/curl https://my.server.local/a1b2c3d4.tar > /mnt/data/supervisor/backup/a1b2c3d4.tar
(Change URL and file names of course. The destination directory should be fine.) - You might want to check file integrity for the file via md5sum or sha512sum etc.
- If you want to be extra tidy, you can remove the cURL Docker image again by executing
docker image rm curlimages/curl - Close the SSH session and open a new one.
- Do not enter the actual shell but instead execute this command to get Home Assistant to notice the newly uploaded snapshot:
snapshots reload - Now log into the Home Assistant web interface or just keep using the console and restore what you need.
- Done!
I hope this saved you a bunch of research because I myself could not find anything quick and practical on this topic.
Thanks for reading!
Installing mod_cloudflare For Apache HTTPd 2.4 On Debian 8 (Jessie) Via Aptitude Repository
[Update on 2019-09-19] Warning: From Debian 9 (stretch) upwards, according to the official documentation Cloudflare has dropped support for mod_cloudflare. Instead they recommend replacing it with the new alternative: the official Apache HTTPd module mod_remoteip.
Hi!
If you are using the Cloudflare proxy functionality, you will find that your web server will end up only working with Cloudflare's IPs instead of the visitors'. After quite some time I thought that there has to be a better way to go about this, and I found mod_cloudflare, a solution officially developed by Cloudflare themselves.
When I was looking at the official Cloudflare documentation on how to install mod_cloudflare for Apache 2.4 on Debian 8 (Jessie) today, I was disappointed to find that they were only recommending manual ways: installing a .deb package or compiling the module yourself.
Luckily I found a guide on how to accomplish the installation with the standard apt-get / aptitude tool for Debian / Ubuntu.
This is how:
- Add the aptitude repository to a new sources list file, e.g. at /etc/apt/sources.list.d/cloudflare-main.list - with this content:
deb http://pkg.cloudflare.com/ jessie main
- Download the Cloudflare repository key and add it to the aptitude known keys:
# wget https://pkg.cloudflare.com/pubkey.gpg # apt-key add pubkey.gpg # rm pubkey.gpg
- Update the aptitude cache:
# aptitude update
- Look at which packages are available in the new repository:
# grep ^Package: /var/lib/apt/lists/pkg.cloudflare.com_dists_jessie_main_binary-amd64_Packages
- Install mod_cloudflare:
# aptitude install libapache2-mod-cloudflare
- Restart the Apache HTTPd service:
# service apache2 restart
Hopefully this way of installing will enable everyone to update / maintain it much more easily and with less one-time use packages installed.
Additionally, this could prove even more useful for people who want to install more Cloudflare packages.
I am confident that this method also works for Ubuntu and other versions of Debian - just replace the "jessie" part in the aptitude sources list file with your distribution major release codename (like "wheezy" for Debian 7 or "vivid" for Ubuntu 15.04).
Thanks for reading!
Original source: https://emtunc.org/blog/01/2016/installing-mod_cloudflare-ubuntu-14-04-apache-server/
Memory Leaks / Problems with Long-Running Symfony / Doctrine Console Applications
Hi!
I recently built several console applications that have to keep running as daemons as part of a more complex website. As soon as I added Doctrine for its highly comfortable ORM functionality, I noticed a significant increase in the applications' memory usage, which made sense because it would load Doctrine's code in order to use it. The worst part of it, however, was that the processes kept eating up more and more memory the longer they ran and with each Doctrine query they executed. Finally the processes ended up being killed by Linux's OOM Killer due to the high amount of memory that they wanted allocated for them.
Clearing the Doctrine Entity Manager ($entityManager->clear()) and triggering PHP's garbage collection manually did not help at all. So I assumed it had something to do with the data that Doctrine accumulates in the background.
During my research I finally stumbled upon this Stack Overflow question: Memory leaks Symfony2 Doctrine2 / exceed memory limit
Apparently, Doctrine uses an SQL Logger to log each and every query it uses when running in debug mode.
Due to the nature of Symfony console applications starting up in the dev environment by default when launching them from the command line, it also kept enabling the debug mode. That in turn enabled the SQL Logger which gathered more and more data and kept it in memory.
I decided to launch the processes by simply manually disabling the debug flag. Using the dev environment is not a problem for me, so I just did the following:
$ php app/console custom:command --no-debug
You could also set the environment variable SYMFONY_DEBUG to 0 before launching the command without the --no-debug flag, as it also respects its value - refer to app/console's source code.
Alternatively, you could start it in a non-dev environment:
$ php app/console custom:command --env=prod
or
$ php app/console custom:command -e prod
or just set the environment variable SYMFONY_ENV before launching it.
This way, the SQL Logger is not enabled.
My processes have been running at stable memory usage size ever since.
Another way would be to deactivate the SQL Logger in the code by principle, but that would be defeating the purpose of the nice built-in features of enabling/disabling the debugging mode, so I rather chose the first path. It might come in handy sooner or later after all, and reverting those changes just to re-enable the SQL Logger would be an unnecessary pain.
I hope this was helpful to you. It certainly took me some time to get behind it.
Using Different Color Schemes with Vim
Hey!
If you have been using the Linux console text editor vim (or: Vi IMproved), you have probably noticed already that at times - especially in files with a large amount of comments - the default color scheme on a black background is less than ideal. Dark blue on black is pretty hard to read and can strain the eyes a lot.
So today I went out to see if somebody had come up with a solution for this particular problem. I saw people who changed console colors by exporting and overwriting certain system variables, and others who edited the default color scheme.
The simplest solution I have found to this problem is just switching the color scheme. You can do that by typing the following in the already open vim session:
:colorscheme desert
where desert is just an example for the scheme of choice. Desert - for me - has just the right color for comments: aquamarine / light blue.
If you are satisfied with the scheme and would like it to be applied each time you launch vim, you can just edit /etc/vim/vimrc (or in my case with CentOS: /etc/vimrc) and add the following line:
colorscheme desert
with desert again, of course, being the chosen color scheme. This would apply this setting automatically for each vim instance that is launched system-wide. If you do not have access to the system-wide preferences or prefer just using it for your own user account, edit the ~/.vimrc instead.
The blog entry I got this tip from (Asher's space) has further instructions on how to edit existing color schemes and even a link to a blog post that explains how to edit the dark blue color for directories in ls listings with color, but I did not feel the need to go that far. If you are interested in that topic I can only encourage you to visit the original post.
Thanks for reading!
Update (2012-01-04):
Okay, looks like pingback isn't working, so here's a direct link to the original blog post:
vi code highlighting: change the default comments color from dark blue to light blue (https://asher2003.wordpress.com/)
Detecting the Linux Distribution / Version
Hi!
Just a quick method to (roughly) detect your linux distribution and version:
$ cat /etc/issue or $ cat /etc/*release
Cheers 🙂
Compiling PHP 5 with IMAP support on SuSE / openSUSE Linux
If you get the following configure error:
configure: error: utf8_mime2text() has old signature, but U8T_CANONICAL is present. This should not happen. Check config.log for additional information.
It's probably because you're missing either the libc-client-devel package or imap-lib and imap-devel. Fire up yast and install those. You should be good to go now 🙂
(I have openSUSE 11.0 and it doesn't have the libc-client-devel package, but I read about it on another page and thought I'd add it, just to be safe 🙂 )