Re: passing environment variables to daemons in rc.d scripts

2023-04-24 Thread Jordan Geoghegan

Hi Antoine, Marcus and Stuart,

Thank you all for your help - setenv via login class was exactly what I 
was looking for!


On 4/20/23 23:44, Stuart Henderson wrote:

On 2023-04-21, Antoine Jacoutot  wrote:

Hi.

You can pas environment variables by creating a login class matching the name 
of your rc.d script in login.conf and adding setenv to that class.

Or create a new file /etc/login.conf.d/(script_name). If you're writing
a port, create pkg/(script_name).login and it will be added to the plist
automatically when you "make update-list".

Thanks for that, worked perfectly!




The problem I'm facing is that it seems that Airflow looks for various 
environment variables such as $HOME, $AIRFLOW_HOME, $AIRFLOW_CONFIG etc and I'm 
seeing no obvious way to pass those requisite environment variables to Airflow 
from my rc.d script. Without these variables set, Airflow annoyingly just looks 
in /dev/null for everything and fails to function.

That seems a strange dir to use by default. Did you perhaps set the
_airflowd user's home dir to /dev/null? If so, try /var/airflow instead.




The users home folder was indeed set to /var/airflow. Turns out the 
/dev/null thing was a red herring - I appear to have found a bug in 
Airflow. When starting the Airflow scheduler with '-D' to daemonize, the 
scheduler program just silently hangs. I got sent down a couple rabbit 
holes because the scheduler continued to send heartbeats yet failed to 
parse dags or run jobs. I didn't fully clue in until I compared the 
process lists between the scheduler when daemonized vs running it in the 
foreground. When run in the forground, all sorts of LocalExecutor and 
other tasks were spawned, unlike when daemonized. It was then made super 
obvious when I realized when daemonized it was leaving zombie processes 
behind after stopping with rcctl/SIGTERM. Curiously, the airflow 
webserver seems to daemonize just fine and I've had no such issues with it.


Long story short, after removing '-D' flag from my rc.d daemon 
arguments, everything worked and I didn't even end up actually needing 
to set any environment variables.


With that said, I'll put together a bug report for the Airflow folks.

Thank you muchly for the pointers.

Regards,

Jordan




Re: PF: Redirect SOCKS connections to another server on a different net

2023-04-24 Thread Charlie
Below comes the solution to this problem. For the explanations on why it works,
you may refer to the original answer [1].

# sysctl net.inet.ip.forwarding=1
# cat /etc/pf.conf
  ...
  pass in on re0 proto tcp from any to (re0) port 1080 rdr-to 10.64.0.1 tag nat
  pass out on wg0 proto tcp nat-to (wg0) tagged nat
  ...

[1]
https://marc.info/?l=openbsd-pf&m=168215778109013&w=2

Cheers,
Charlie



Re: Increasing the log level for php

2023-04-24 Thread Daniele B.
> I would first try running php-fpm-8.1 in the foreground with -F

Just to mention that you can go easily in foreground also from inside the 
php-fpm.conf.
There is a directive for that.

Note that Web server "500 server error"  maskerates always very well
PHP errors if you don't incrise error reporting by .ini or code as the setting
comes as default ones; especially known in shared hosting selfcoded
platforms. 

Below some other hints that I wrote but not posted yet.

However I'm glad you solved it, Robert.


-- Daniele Bonini


Apr 23, 2023 18:59:08 Daniele B. :

> Additional hints.
> 
> As stated here: https://www.phpbb.com/support/docs/ug/
> among the basic software requirements of phpBB figure the followings:
> gd* (by implicit deduction)
> json
> mbstring
> XML support
> corresponding PHP lib for the database you use
> 
> All pretty standard except the last one, in case you are using SqlLite 
> requiring libsqllite.
> In this case point to: https://www.php.net/manual/en/sqlite3.requirements.php
> 
> An other one:
> 
> As from ver 8.1, PHP has *broken compatibility* with the past causing mosty
> deprecated messages. Mainly it is matter of:
> - optional versus required parameters in function declarations (NB: 
> parameters order)
> - failure of buildin functions trying a null conversion to string (NB: 
> important for string functions)
>   related to this matter is the need to read GET and POST params to 
> discriminate
>   on null, eg better the following:
>   filter_input(INPUT_GET, "param1") ?? "";
>   than the usual:
>   filter_input(INPUT_GET, "param1");
> 
> Please refer to: https://www.php.net/migration81
> 
> 
> 
> -- Daniele Bonini