zam install - hobbit-ns/con-discord GitHub Wiki
Zambia usually installs onto a Unix variant, usually Linux, equipped with a set of server-side software commonly called the "LAMP stack" (Linux, Apache, MySQL, PHP). This is intended as a guide to setting up the basics of the platform to host a Zambia deployment.
This document is useful to study, as it describes the latest recommended process from Amazon. This testing was done on the Amazon "Linux 2" AMI type. It is assumed that the reader knows the basics to start up an EC2 instance and use an SSH private key to log in, usually as "ec2-user", via its temporary public IP address or a persistent "elastic" address assigned later.
It is more efficient to type "sudo bash" once and stay in the resulting root shell, rather than have to precede everything with "sudo" over and over. Once root access is attained on the machine, essential steps follow.
Type: amazon-linux-extras list to see what the latest add-on packages are. Look for lamp-<something> in the output. The name of this linux-extras "LAMP kit" may change, and while it brings in several basics of PHP and MySQL clients, it doesn't give you everything you need up front. To continue, perform the following steps:
- amazon-linux-extras install lamp-mariadb10.2-php7.2
- yum install mariadb-server
- yum install httpd
- yum install mod_ssl
- yum install php-xml (may already be present)
- yum install php-mbstring (may already be present)
- yum install git-core (optional, for direct repo fetches)
In the default setup, the webserver root is under /var/www/html, so we aim to confine all of the files relevant to Zambia under that same root.
The default location of the database under /var/lib/mysql should suffice, since database access won't be affected by file path restrictions for PHP or the webserver.
Starting the database system should be able to initialize everything:
- systemctl start mariadb
(Yes, the "systemd" service name is "mariadb" instead of "mysqld".)
Run tail -30 /var/log/messages to see the
resulting startup messages. You should see references to
"mysql-prepare-db-dir" and the like, indicating that the database was
created and the server is now running.
Let's connect to it:
- mysql -u root
MariaDB> show databases ;
(the trailing semicolon is important! "show databases" is a SQL command.)
You should see something like this from your command and the output:
MariaDB [(none)]> show databases;
+--------------------+
| Database |
+--------------------+
| #mysql50#.rocksdb |
| information_schema |
| mysql |
| performance_schema |
| test |
+--------------------+
5 rows in set (0.00 sec)
Type exit or hit <control-D> to leave the MySQL client.
Now, let's secure the database a little better:
- mysql_secure_installation
Set a root password and record it somewhere safe. It doesn't have to be super-complex; access to the database machine itself should be very limited and normal traffic from the webserver will run under a different account anyway. Go ahead and remove anonymous access, though, and if the webserver and the database server will be on the same machine then remote access can be disabled too.
Note that this "root password" is only for access within the database, not the same as "root" on the Linux system. This can be confusing sometimes. We will create another database user for Zambia access later. And if that wasn't enough confusion, there will be "users" defined within Zambia itself, e.g. program participants and support staff for the event.
Make sure that root access works properly with the new password, by adding the -p flag to the previous test:
- mysql -u root -p
Enter the new password, and you should see the "Mariadb>" style prompt.
Here's a nice clear MySQL tutorial with a good search-engine for looking stuff up.
still unclear; we can "git clone" under the web dir, but there's an open question of where to put the running "webpages" dir vs. db_name.php
To retrieve the latest copy of Zambia and place its runtime files under the web server tree, we can do
- cd /var/www
- git clone https://github.com/olszowka/zambia.git zambia
- mv zambia/webpages html/zambia
This makes the working piece of Zambia accessible via the webserver:
http://YOUR-SERVER/zambia/
but leaves its utility files and documentation inaccessible to normal
web requests. (If the server is intended for nothing but Zambia in the
first place, the webpages/ directory can be moved to simply replace the
html/ directory entirely instead, in which case http://YOUR-SERVER/
directly accesses the Zambia system.)
Note that this URL format depends on Apache looking for index.php
as one of the default index files.
Both MySQL and PHP need a notion of local timezone, and MySQL needs some additional tables loaded to support it. An additional utility is provided to install timezone data into MySQL. Examine the files under /usr/share/zoneinfo to find your correct timezone file. Here is an example based on US Eastern Standard time:
- mysql_tzinfo_to_sql /usr/share/zoneinfo/EST EST | mysql -u root -p -D mysql
Enter the database root password, and the timezone data should load.
Here we copy the template Zambia configuration file and begin customizing it for the event in question.
- cd /var/www/html
- cp zambia/db_name_sample.php ./db_name.php
Use your text editor of choice to edit db_name.php, and (following the same
example of Eastern Standard time) set the two variables
DB_DEFAULT_TIMEZONE
PHP_DEFAULT_TIMEZONE
to "EST". While editing this file, it's the opportunity to begin
configuring for the event itself. Decide on a database name, user
account name and password that Zambia will normally run under, and set
DBDB, DBUSERID, and DBPASSWORD accordingly. CON_NAME should reflect what
your event is. The other fields can get set later; we just need to get
basic functionality in place here.
## remaining steps to doc: refer to zambia Install/INSTALL
make running zambia db user(s)
> create database zambia;
> grant all on zambia.* to 'dbuser'@'localhost' identified by 'dbpassword';
> flush privileges;
configure PHP right, limit its open_basedir scope (/var/www ?)
make sure httpd is NOT configured to allow ".phps" source viewing
start httpd (and php-fpm if it doesn't auto-start under that)
fiddle AWS security-group for webserver access
test stub <?php phpinfo(); ?> file in /var/www/html, examine output
edit and place db_name.php appropriately (/var/www ?)
fix db_functions.php pointer thereto if needed, really outside web tree but within basedir
load the demo DB or the empty DB, etc ; test access
install real SSL certs?? and test functionality along TLS path
start importing con data
set httpd, php-fpm, mariadb to auto-start at boot ... maybe ...
which junk system daemons to permanently disable [supply a script?]
=== pre fodder txt ===
# so now we have "httpd", configs: /etc/httpd, conf*
# documentRoot /var/www/html ... stock defaults
systemctl start <various>
Go muck in /var/www/html, and hit from mist: heh, phpinfo() goes for PAGES!
huh. /etc/my.cnf, points to my.cnf.d .. data is /var/lib/mysql by def.
that's under [mysqld], not [mariadb], interesting
revector to /dev/shm/mysql before starting it... need to create, uid 27/27
internally did: mysql-prepare-db-dir, and whined a lot about "root password"
mysql_secure_installation is indeed a script, deal with it later ... but now,
--> MariaDB [(none)]> show databases;
+--------------------+
| Database |
+--------------------+
| #mysql50#.rocksdb |
| information_schema |
| mysql |
| performance_schema |
| test |
+--------------------+
aha: it's running. I see port ::3306 so it's still using that dumb v6 fmt
OR JUST: ...mysqld --pid-file=PID --socket= [defaults the tcp port!]
Also noted, that mysql.user every entry starts with the concept of SOURCE
of the connection, thus "lamp-test" was actually 172.16.blah.
maybe want to add --general-log --general-log-file=NAME --> ok, can tail it
mysqld also *really* resists signals; ^C etc don't work, have to kill from
external, and it goes through a bunch of shutdown hair before dying.
## apache note(s) for later..
ooh: Had to run "mandb" to make man-index pick up, say, "-k httpd"
disable ipv6 listen?
some blog sez: do "listen 0.0.0.0:80" instead of "listen 80"
rc.local also needs to be +x, thats why it didnt run, now it's ok
won't get too hairy on lockdown/disable here, it's a test box for now
but if someone else wants to poke at it, we can let that.. change the relay
XXX: have to go back through all this and test fire-up-new-db --> working,
plowing into live doc
## 201209: okay, trying totally generic restart on web/php/sql.
config: nothing different in httpd / php-fpm
config: datadir changed in my.cnf.d/whatever, keep it volatile
nothing present in dbdir: fail, wants empty datadir at least extant
already-initialized present: fail, prepare-db-dir wouldnt run
this shit is awfully picky, why doesnt it just follow on to what's there
I *was* running this as root...
okay, needs empty dir already chown/chgrp: *now* it starts, and populates.
so now it's listening on *: 3306 *and* the lcl socket. Whatever
we won't want that in production I imagine, just lcl
Playing with "grant" : looks like host wildcard is "%"
effectively it's doing::
INSERT INTO user (Host,User,Password)
VALUES('localhost','my_user',PASSWORD('my_pass'))
and then fiddling with privileges.
Want to ultimately fetch Zam from its freshest repo: yum install git-core
git clone ... yup, got a tree. -> that'll created "zambiademo"
and in Install/, there's EmptyDbase.dump to source
or the more fleshed-out sample/demo ones
... installed ... per the Doc/INSTALL thing, more or less; side-trip to create
a different sql user that's not root and can romp in "zambiademo" but little
else. Once the tables are created etc an even less powerful user could do.
"zam" can also mess with "classicmodels" if we want to tutorial...
--> up to the point where I could hit it with a browser, relayed, but the
php chokes on "timezone" crap it got from ../db_name.php
[which gets resolved VERY interestingly across a symlink to zam/]
## 201210: looking at the zam adduser script, among others..
ARGH :: php *can* reach directly outside of DocumentRoot, at the very
least on a "require" to pull in definitions. Meep.
So we could totally write a show-me-any-file handler.
## 201211... still seeing these stupid errors, as mailed to PO, from
[1]- 4652 Running tail -n 45 -f /var/log/httpd/access_log &
[2]+ 5996 Running tail -n 45 -f /var/log/php-fpm/www-error.log
plus usual journalctl -f.
PO sez, about timezones:
https://dba.stackexchange.com/questions/120945/how-do-i-resolve-this-error-error-1298-hy000-unknown-or-incorrect-time-zone
which suggests mysql_tzinfo_to_sql /usr/share/zoneinfo [/*...] to load
timezone names into some piece of mysql.* via stdin -D mysql .
--> I think I have that ok now, mysql -> "Eastern", php -> "EST" works
aha: need to install php-xml, apparently.. *as noted* in Peter's doc
how the f do I see its files?
aha: yumdownloader, needs proxy up..
rpm2cpio THING | cpio -it, etc
would install shit like /usr/lib64/php/modules/dom.so ... so yeah.
also /etc/php.d/20-dom.ini
so, --> installed it, now let's look around.. dom.ini: "extension=dom" bfd
it also brought along libxslt-whatever.amzn2.x86_64 too
still err, have to stop php-fpm and let it restart??
yes, apparently that gets past the class DOMDocument or DomDocument or wha,
but now we're on to the next stupid error, undef mb_ereg_replace() in XSLT
-> now have to install php_mbstring too, arrgh ... stop/start php-fpm again
amzn's "LAMP php kit" really left out some things, didn't it.
YOW! Got the login page! now what...
browser with js: aha, the "mark of Zambia" logo
Demo db did create a couple of sample users, so... log in:
1001 initialPW staffComp: permroleid 1,2,12 == admin, staff, senior
1002 initialPW participantComp: permroleid 3 == prog-participant
via select * from PermissionRoles;
-> SQL tables are *case-sensitive*!! everything else isn't.
But what is the actual *userid* ?? not obvious from sample users csv..
ah, they're not in there yet, only "1" and "2" and pw not obvious either.
scripts/add_zambia_users depends on various hard relpaths, esp. db_name ??
Now I can log in as 1001/initialPW ... and, barf again! no Phase set up,
no 'zambiademo.Phases' table yet. Now, how do you admin that if you can't
log in as admin in the first place?? heh
I appreciate that all the scripty-stuff is loaded from local, I wish more
entities would do that instead of calling out to jquery.com and shit.
Silly hack: changed root db account to something else:
update user SET User = 'god' where user = 'root' ;
and it worked! didnt donk password access, so pw hashing is independent.
## other security notes
# --> moved ssh port to 44 in here, just for yuk, doesnt really matter
# and with a, aws ec2 ... from mist, shut 'er down for the night while watch.
wtf is this "ec2-instance-connect.service" crap, "host key harvesting"?
runs aws/bin/eic_harvest_hostkeys..
--> *disabling* : that, and atd, chronyd, rpcbind/.socket, brandbot/.path,
gssproxy, postfix[!], crond, amazon-ssm-agent [that took a while]...
## stuff that got "systemctl disable"d, or at least stopped in rc.local
amazon-ssm-agent
ec2net-scan
lvm2-lvmetad
brandbot
brandbot.path
atd.service
chronyd.service
crond.service
libstoragemgmt
gssproxy.service
postfix.service
rdisc.service
nfs.service
rpc-rquotad.service
rpcbind.service
rpcbind.socket
rsyncd.service
rsyncd.socket
## /etc/php.ini ::
; http://php.net/open-basedir <-- empty by default, cat.php /etc/passwd
;open_basedir =
; open_basedir = "/var/www/html" <-- prevented access to shm-based zam/
; open_basedir = "/dev/shm/zam" <-- stopped zambia from working cuz ../db_*
; open_basedir = "/dev/shm" <-- let zambia work, no /etc/read-a-file, and
; HTML under the rest of the webroot is still available too.
## excerpt from /etc/my.cnf.d/mariadb-server.cnf ...
# datadir=/var/lib/mysql
# _H* : keep it volatile during early play
datadir=/dev/shm/mysql
# while here, try this as another way to deal with the Phases problem:
# lower-case-table-names=1 <-- *Nope*, can't do AFTER tables exist!
noted later: after fixing "Phases" -> "phases", only lowercase table..
I can actually navigate in Lynx, no js really needed for the basics.
# noting, for manual fix of Phases maybe:
We can rename a table using the ALTER TABLE statement as follows:
ALTER TABLE old_table_name
RENAME TO new_table_name;
The ALTER TABLE statement can rename a temporary table while the
RENAME TABLE statement cannot.