# Set proxy server for rc.d / periodic scripts?



## mickey (Feb 19, 2019)

My network permits internet access only through a proxy server which is normally configured via the usual (http|https|ftp|no)_proxy environment variables. Unfortunately service(8) runs rc.d scripts in a clean-room environment (env -i) which causes scripts that require network access (i.e. service ntpd fetch) to fail because they are unable to access the network. The same thing seems to be happening with some periodic scripts that require network access:

```
Checking for packages with security vulnerabilities:
pkg: http://vuxml.freebsd.org/freebsd/vuln.xml.bz2: Operation timed out
pkg: cannot fetch vulnxml file
```
Is there any _supported_ way to have these scripts use a proxy server for internet access?


----------



## SirDice (Feb 19, 2019)

NTP can't be proxied so you'll have to turn off the script (or configure it to use an _internal_ NTP server). For pkg(8) (this includes pkg-audit(8)) can easily be proxied by setting in pkg.conf:

```
pkg_env: {
               http_proxy: "http://myproxy:3128",
           }
```

Note that periodic(8) scripts are _not_ services and thus have nothing to do with service(8) or rc(8).


----------



## mickey (Feb 19, 2019)

SirDice said:


> NTP can't be proxied so you'll have to turn off the script (or configure it to use an _internal_ NTP server).


It's not so much about NTP (that uses my internal NTP server) than about fetching the ntp-leapseconds file via http in case it has expired. This is done from /etc/periodic/daily/480.leapfile-ntpd which uses `service ntpd onefetch`. This command fails for the reasons mentioned. As a workaround for the problem I created a script that only exports the *_proxy environment variables and source that script from /etc/rc.conf. I confirmed that it is working for service(8), but I would hardly call it a solution.



SirDice said:


> For pkg(8) (this includes pkg-audit(8)) can easily be proxied by setting in pkg.conf:
> 
> ```
> pkg_env: {
> ...


Thanks, that's good to know, although I suspect pkg(8) is not the problem in this scenario. It's more likely that the periodic scripts are run in a similiar clean-room environment as is the case for service(8). Be it intentionally (env -i) or unintentionally (/etc/profile never sourced). I guess a possible workaround could be to source the proxy-settings script from /etc/periodic.conf or - as the periodic scripts are most likely run by cron(8) - to incorporate proxy settings in the crontab itself.



SirDice said:


> Note that periodic(8) scripts are _not_ services and thus have nothing to do with service(8) or rc(8).


I'm aware of that, nevertheless the source of the problem is the same, the *_proxy environment variables not being set and/or being flushed.


----------



## SirDice (Feb 19, 2019)

Not sure if this is going to work but rc.conf is a shell script that's sourced a bunch of times. Setting http_proxy in rc.conf might actually work for services.


----------



## olli@ (Feb 19, 2019)

mickey said:


> It's not so much about NTP (that uses my internal NTP server) than about fetching the ntp-leapseconds file via http in case it has expired. This is done from /etc/periodic/daily/480.leapfile-ntpd which uses `service ntpd onefetch`. This command fails for the reasons mentioned. As a workaround for the problem I created a script that only exports the *_proxy environment variables and source that script from /etc/rc.conf. I confirmed that it is working for service(8), but I would hardly call it a solution.


Right, rc.conf should only be used for setting variables.

However, you should be able to set `ntpd_env` to a list of environment variables, or set `ntpd_env_file` to a file that contains the environment variables. For example, add this line to /etc/rc.conf:

```
ntpd_env="/etc/ntpd.env"
```
Then create a file /etc/ntpd.env with lines like these:

```
http_proxy=...
https_proxy=...
ftp_proxy=...
```


----------



## mickey (Feb 19, 2019)

olli@ said:


> Right, rc.conf should only be used for setting variables.


Well, in a way that's exactly what it's doing ... setting (environment) variables 



olli@ said:


> However, you should be able to set `ntpd_env` to a list of environment variables, or set `ntpd_env_file` to a file that contains the environment variables. For example, add this line to /etc/rc.conf:
> 
> ```
> ntpd_env="/etc/ntpd.env"
> ...


Is that feature documented somewhere? I don't see anything in rc.conf(5) or rc(8). But then again, it would only work specifically for ntpd, although I've not yet found any evidence of other rc.d scripts requiring network access. I was also thinking about adding the proxy settings to /etc/login.conf but given my recent experience with that particular approach, I tend to believe it wont work either.


----------



## olli@ (Feb 19, 2019)

mickey said:


> Is that feature documented somewhere?


Well … It is “documented” in /etc/rc.subr, in the description of the `run_rc_command` function.


----------



## drTr0jan (May 20, 2019)

Unfortunately ntpd_fetch_leapfile() subroutine doesn't support ntpd_env option

PR 237999


----------



## kisscool-fr (Nov 11, 2021)

I know it's old but I had to deal with that recently.

As an alternative I have done things like this.

Define proxy settings in /etc/profile and create a wrapper to fetch in /usr/sbin as it is, by default, before real fetch from /usr/bin in $PATH. 


```
#!/bin/sh

[ -f /etc/profile ] && . /etc/profile ]

/usr/bin/fetch $*
```

With
`# chmod a+x /usr/sbin/fetch`


----------



## mickey (Nov 12, 2021)

The solution that has worked for me since back then is to keep proxy setting environment variables in a separate file, which is either a static configuration file, or dynamically updated with values received via DHCP. This file is then sourced at the end of all these files: /etc/rc.conf, /etc/periodic.conf and /etc/profile. A separate csh style proxy settings file exists for sourcing it from /etc/csh.cshrc. If anyone knows of a shell-agnostic way to set environment variables, please let me know.


----------



## covacat (Nov 12, 2021)

ntpd_env_file works


----------

