to set password
printf "raspberry\nemonpi2016\nemonpi2016" | passwd
to set hostname, won’t get applied til reboot.
sudo sed -i "s/$HOSTNAME/$hostname/g" /etc/hosts
printf $hostname | sudo tee /etc/hostname > /dev/null
should really be
sudo apt-get -y dist-upgrade
sudo apt-get clean
need to remove php-redis to avoid conflicting packages since you are also installing via PECL.
printf "\n" | sudo pecl install redis Mosquitto-beta
so that you get v0.4.0 (2017-03-13) rather than v0.2.2 (2014-05-12)
I would also seize this opportunity to put all the non-www emoncms modules in a dedicated folder so emoncms can be updated easily using 2 “for each in” loops one for the www path and the other for the non-www, the symlinked folders and core folders would be ignored if updater tests for being a git repo (like the one in usefulscripts).
The installation of the modules could be a simple loop rather than verbose, as could installing and enabling the emoncms services. But that’s just tidier, it still works just fine.
# Symlink emoncms module folders here...
that bit’s not going to be easy unless you make sure there is a common theme across modules, eg each non-www module has a subfolder of the same name for the www bit.
The emoncms module branches could do with mirroring the “stable” and “master” (I know some do already) so that ALL are stable, currently all installed modules would be “master”.
A good start, I’ve been doing it this way for many years, if you recall I offered you an image build script leading up to the emonPi launch. I also use a heredoc to set up a proper vhost rather than use the 000-default and set up UFW and few other bits if you are interested.
Personally I would split this into seperate bits eg an emoncms installer and a emonhub installer so that different images (eg hdd or non-Rpi) can be created using the same parts, just a custom main script.
The script should be written with more verbose notes and comments so that the script is the documentation, done right it can also be a webpage.
Take a look at https://emonsd.duckdns.org, I just setup a quick dynamicdns to show it can be linked to an oem site (instead of duckdns).
The code for the “buildguide” linked from that page is
##### Although this file is written in markdown and has an `.md` extension, it is an executable bash script.
##### The first line of this file is a bash shebang and that is mandatory for the script to execute correctly.
##### The sheband and any other evecutable code or command lines are all indented by 4 spacesfor better reading when viewing on GitHub or as a webpage.
##### All comments like this are written as a series of individual notes for each point explaination of each step and
echo "this is code"
##### To avoid the need to harcode various path and details we have the option to include a seperate configuration file
If you clone that repo and run
emonSD/build.md it still runs like any other
.sh script, the
.md just lets it be used directly as a webpage.
[email protected]:~/emonSD$ ./build.md
this is code
The website, docs and script and there image cannot ever be out of sync as they are the same thing, only one place to edit!
all comments are directly linkable eg emonSD/build.md at master · pb66/emonSD · GitHub since they are headings not just text, this is useful for discussions without linking to the lines in the github repo. The hashes of the heading make the comments invisible at runtime as usual.
The 4 space indents do not effect the running of the code, but they do make the code looked fenced on the webpage.
Great, but you have’nt used the version I made changes to, so the rotated logs will stay in RAM, with my version, the rotated logs are moved out of the ram&sync cycle, they are held only on disc, this reduces the size in RAM and the effort required to sync and load at startup.
See the changes here Comparing azlux:master...pb66:pb66 · azlux/log2ram · GitHub