Showing posts with label lapp. Show all posts
Showing posts with label lapp. Show all posts

Thursday, October 21, 2021

local machine (localhost) LAPP, email

Both of these must be entered for the monitor to remain on during inactivity. Neither command by itself is enough to keep the monitor alive.

$ xset -dpms
$ xset s noblank

With these two entered, the screen will still be receiving a signal, but it's just for the backlight, not for any display conent. If we want the display content to remain during inactivity, we must do the two above AND add the following.

$ xset s off

Do we even need this project? Re the LAPP: "no, but helpful". Re the email: probably "yes, for understanding dashboard alerts". LAPP or any other monolithic CMS (XAMP, LAMP) that require learning PHP might be a waste if we can chain cloud services and so on (eg. read comments under this video).

Since LAPP elements are servers, they typically require user switching, individual configuration, or other permission issues. A separate post will deal with production configuration like that. I wrote this one aiming for a localhost light development environment (besides Docker). Additionally, I've attempted to view each LAPP element independently, in case we learn of an app that requires only one element, eg the PHP server, or just a relational database. I also subbed out the Apache "A" for another "L", lighthttp: LLPP. More commonly though, even browser based apps (eg Nextcloud - go to about 8:30) still use a CMS LAMP, LAPP, LNPP, etc. Electron, Go, Docker, won't be covered here.

LAPP

Linux (L)

For both LAPP and email, verifying /etc/hosts is properly configured for IPv4 and 6 for localhost smoothness. Otherwise we typically already login as some user, so we shouldn't have permission issues if everything else is well configured.

PostgreSQL (P)

# pacman -S postgreqsl
# pacman -Rsn postgresql

Lunatic designers really really really don't want a person running this on their own system under their own username. There's no security advantage to this, just poor design. This is almost more difficult than the design of the database itself.

After installing with pacman, add one's username to the postgres group in /etc/group, then initialize the database. Use...

$ initdb -D /home/foo/postgres/data

...instead of the default:

$ initdb -D /var/lib/postgres/data

Attempt startup.

$ postgres -D '/home/foo/postgres/data'

If starting-up gives the following error...

FATAL: could not create lock file "/run/postgresql/.s.PGSQL.5432.lock": No such file or directory

...run the obvious

# mkdir /run/postgresql
# chown foo:foo /run/postgresql

Just do the above, don't believe anything about editing service files or the postgresql.conf file in /data. None of it works. Don't even try to run it as a daemon or service. Just start it like this:

$ postgres -D '/home/foo/postgres/data'

Now that the server is up and running, you can open another terminal and run psql commands. If you run as user postgres (see below), you'll have admin authority.

$ psql postgres

If a lot of data has been written, a good exit phrase to make sure all is safely written:

$ psql -c CHECKPOINT && pg_ctl stop -m fast

PHP (P)

Link: CLI flags ::

# pacman -S php php-pgsql
# pacman -Rsn php php-pgsql

PHP server setup (8:04) Dani Crossing, 2015. Old, but not outdated.
php.ini basics (7:25) Program With Gio, 2021.

If we've got a dynamic website, we typically need PHP (server) and then some JavScript(browser/client) to help display it. The less JavaScript the better (slows browser). I consulted the Arch PHP Wiki .

standalone PHP - start/stop

Standalone PHP is easier to troubleshoot than when starting Apache simultaneously. Stopping is CTRL-C in the terminal where it was started. Startup with web-typical TCP port 80, however leads to a permission issue.

$ php -S localhost:80
[Fri Oct 23 11:20:04 2020] Failed to listen on localhost:80 (reason: Permission denied)

Port 80 works when used with an HTTP server (Apache, NGINX, etc), but not standalone PHP (not sure why). So, use any other port, eg port 8000, and it works.

$ php -S localhost:8000
[Fri Oct 23 11:20:04 2020] PHP 8.0.12 Development Server (http://127.0.0.1:8000) started

See this to determine when best to use index.html, or index.php. But there are at least 3 ways for PHP to locate the index.html or index.php file:

  1. before starting the server, CD to the folder where the servable files are located
  2. specify the servable directory in the startup command
    $ php -S 127.0.0.1:8000 -t /home/foo/HTML
    $ php -S localhost:8000 -t ~/HTML
  3. edit /etc/php/php.ini to indicate file locations...
    # nano /etc/php/php.ini
    doc_root = "/home/foo/HTML"
    ... however this strategy can lead to mental illness and/or lost weekends: sometimes the ini file will not be parsed. Good luck.

First, take a breath. then verify which ini file is being used.

$ php -i |grep php\.ini
Configuration File (php.ini) Path => /etc/php
Loaded Configuration File => /etc/php/php.ini

If you have modified the correct ini file, hours and hours of finding the correct syntax for

standalone PHP - configuration and files

Links: PHP webserver documentation :: Arch PHP configuration subsection

PHP helpfully allows us to configure a document root, so I can keep all html files (including index.htm) inside my home directory. The open_basedir variable inside the configuration file (/etc/php/php.ini) is like a PATH command for PHP to find files. Also, when pacman installs PHP dependent programs like phpwebadmin or nextcloud it default links them to /etc/webapps, because this is a default place PHP tries to find them. Even though they are installed into /usr/share/webapps. So if I had a folder named "HTML" inside my home directory, I'd want to at least:

# nano /etc/php/php.ini
open_basedir = /srv/http/:/var/www/:/home/foo/HTML/:/tmp/

email local

Link: simple setup :: another setup :: notmuch MTA setup

$ mkdir .mail

We also need a mail server on the machine but which only sends to localhost and then only to one folder in /home/foo/.mail/ inside localhost. However, instead of setting up local email alerts, why not skip all of that (for now), and run a log analysis program like nagios?

We want to configure the lightest localhost system setup for email that we can read on a browser. Once we can reliably do alerts on, eg. systemd timers, or some consolidating log app (eg,Fluentd), or some Python/Bash script triggers, other things are possible. Our simplest model takes timer script outputs and sends email to the local system (out via SMTP port 25).

CLI suite

Linux has some default mail settings: mail to root is kept at /var/mail/root, user typically in ~/mail. It appears we'll need a webserver, no small email systems have this built-in. Appears Alot can be our MUA. It is available on the repositories, and can be configured with other light localhost services as described here.

cli configuration

browser MUA

Once the above configured, we can use a browser MUA. For Chromium, the Chrome store, has an extension for notmuch, called Open Email Client. configuration information is provided.

Friday, September 4, 2009

layman data II

related links
Apache   PHP   PostgreSQl
security modifications to avoid root
LAPP on Redhat (very helpful)
clear PHP/Apache compile notes


A difficult intercomplexity, combined with an annoying resource drain of running Apache, PostgreSQL (or MySQL), PHP, and a browser (taken together, a LAMP) are required these days. If one has photos or a lot of other files, something besides file folders are needed and they cannot be managed without a LAMP unless one has a CS degree or can afford Oracle. I run a LAMP on my website to make files accessible, but the provider where I park the site has older versions of all this software. This makes the LAMP vanilla and slower (eg., no InnoDB). Additionally, there are no options for PostgreSQL.

Since I prefer PostgreSQL, for the LAMP on my local drive, I created a LAPP, substituting Postgres for MySQL. Even on a local drive, security issues arise. Apache, Postgresql, PHP, and some browsers require ports. I want to be sure no ports are open to the outside. Learning how to lock-down Apache, PostgreSQL, and PHP to make them only localhost accessible is a work in progress. Configuration files need to be altered for localhost only, but it appears there is more to it than this, if one is simultaneously connected on the Web.

On this local drive, running hybridized Slackware (Zenwalk), a reliable LAMP exists out of the box, but morphing it to a PostgreSQL LAPP required compiling PostgreSQL and PHP (see "Notes" below). The kernel didn't require alteration and a recompile, thankfully.

Notes

Install PostgreSQL(source, don't use netpkg) and MySQL(netpkg) first. In Zenwalk, PHP is precompiled without PostgreSQL support. PHP must therefor be recompiled with it: "--with-pgsql=/usr/local".

Default Users, Ports, Home

Postgresql - user:postgres, port 5432, /usr/local/pgsql. Apache - user:root, port 80, /etc/httpd.conf. PHP - /usr/local/lib/php. MySQL - user?, port 3306, usr/share/mysql. I compile Postgresql instead of netpkging it because of a Catch-22 that occurs after installation. One would have to log in and out every time they wanted to use the database or create group permission trees. On a standalone, it's easier to compile Postgresql and initialize with the user as the owner instead of "postgres". Create databases using

PostgreSQL

FIRSTRUN DBMS - Compiling is easier downstream than Zenwalk. When compiling, simply supply one's username during initdb, eg. if one's username were "foo": $ initdb foo --encoding=utf8 --locale=POSIX .Then just make some directory in /home like "/home/pgsql" and # chown -R 1000:100 /home/pgsql so "foo" can use it at will. If using Zenwalk, postgresql.conf and pg_hba.conf must be configured prior to first run. Zenwalk also makes the default user postgres, so its password needs to be created: # passwd postgres, and enter a simple password. A note of confusion for Zenwalk is that "postgres" is both the god user of the DBMS, but also a command to start the DBMS ("postmaster" is deprecated).
START/STOP DBMS - # service start/stop postgresql (Zenwalk), or # postgres -D /var/lib/pgsql/data/ -r logname.txt. This second command starts the database at its default location and provides a logname of choice.
DATABASE FILES Zenwalk installs a PostgreSQL tablespace at /var/lib/pgsql/data, but if installing from source they go to /usr/lib/pgsql. # createdb -U postgres -W -D /var/lib/pgsql/data/sub01 -E utf8 -e employees.

Apache

SECURITY Once it's running, if Apache's listening for connections, it's a significant security problem. Set it to only listen on port 80, so it only listens to localhost. Skype also uses Port 80, but you can reset Skype to, say, Port 81, in its advanced settings. Meanwhile, to change Apache:
# nano /etc/apache2/ports.conf
Listen 127.0.0.1:80
START/STOP - # service start/stop httpd (Zenwalk), or # apachectl start/stop (any distro). Checkit by pointing browser to "http://localhost".
CONFIG FILES - Netpkg handles it, but following PHP recompile, Apache configuration tweaks are necessary for PHP serving. A short list is here. Additionally, one must open /etc/apache/mod_php.conf and provide the complete path to libphp5.so, typically /usr/libexec/apache/libphp5.so, if it's not in there. Following changes, restart httpd, which should initialize PHP.
HTML FILES - (Zenwalk) We can serve files from anywhere on our hardisk through the browser, but it's easiest to put them in /var/www/htdocs/, because this is the default. To write to here from logs or anything, it can't be done easily since /var/www/ is owned by root. A solution is to create a new group.

PHP

START/STOP - # php -v. This command checks for the version. PHP loads as an Apache module, not as a separate program. I used #netpkg remove php to remove the Zenwalk version of PHP. I did this because the netpkg (Zenwalk) version fails to support PostgreSQL.

COMPILE - necessary for PostgreSQL; netpkg PHP does not support Postgres. The configuration phase, prior to "make", is critical. The correct syntax for the PostgreSQL functionality is --with-pgsql=/usr/local. However other options, can be useful. Taking most situations into account, a reasonable configure string might be:
$ ./configure --with-apxs2=/usr/sbin/apxs \
--with-pgsql=/usr/local \
--with-mysql=/usr/share \
--with-libxml-dir=/usr/lib \
--with-curl=/usr/bin/curl \
--with-zlib \
--with-gettext \
--with-gdbm \
--enable-inline-optimization \
--enable-track-vars

"Make", then root "make install"; it installs to /usr/local/lib/php. Copy the ini files to there: # cp php.ini* /usr/local/lib/php/. Pick one of the two to be the ini file, eg # cp php.ini-development /etc/apache/php.ini. It can be tweaked later.



Other