[Support] Linuxserver.io - SWAG - Secure Web Application Gateway (Nginx/PHP/Certbot/Fail2ban)


Recommended Posts

Ok I think i've got it.  I've added a server directive and it works.  Even got a directive for port 80 to redirect to the https counterpart.  But is there a way to have a catch all port 80 directive that forwards to it's https counterpart ?  Ie : any request to http://subdomain.domain.com to https://subdomain.domain.com ?

 

server {
	listen 80;
	server_name library.mydomain.com;
	return 301 https://$host$request_uri;
}
server {
	listen 443;
	server_name library.mydomain.com;
	
		location / {
		proxy_bind              $server_addr;
                proxy_pass              http://<redactedIP>:<redactedPORT>;
                proxy_set_header        Host            $http_host;
                proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header        X-Scheme        $scheme;
               }
        
}

 

 

Link to comment
9 hours ago, aptalca said:

Your current cert is good until May 6th.

 

You likely had an older cert that was never revoked, and it is about to expire. You probably just deleted the appdata folder. Nothing to worry about. 

 

How did you find out the current cert was good until May 6?

Link to comment
2 hours ago, stefer said:

Ok I think i've got it.  I've added a server directive and it works.  Even got a directive for port 80 to redirect to the https counterpart.  But is there a way to have a catch all port 80 directive that forwards to it's https counterpart ?  Ie : any request to http://subdomain.domain.com to https://subdomain.domain.com ?

 


server {
	listen 80;
	server_name library.mydomain.com;
	return 301 https://$host$request_uri;
}
server {
	listen 443;
	server_name library.mydomain.com;
	
		location / {
		proxy_bind              $server_addr;
                proxy_pass              http://<redactedIP>:<redactedPORT>;
                proxy_set_header        Host            $http_host;
                proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header        X-Scheme        $scheme;
               }
        
}

 

 

Remove the server name directive from the block listening on port 80 so it will respond to any request. The return line in there is already set to redirect all http requests to their https counterpart

Link to comment

I had that before! Kinda, from an example I found : 

server {
	listen 80;
	server_name _;
	return 301 https://$host$request_uri;
}

I removed the server_name directive in that and removed the one I put for my library server directive and it works, thanks!

 

Now if I can get my tt-rss redirect to work i'll be golden!  

 

Link to comment

I'm suddenly running into a problem where it appears LetsEncrypt container won't load because 443 is already in use. But I don't even have SSL enabled on my server, and prior to disabling, I sent the HTTPS port to 444. No changes to my server config, but I did have an unclean shutdown and am having a parity check (but that really shouldn't have any effect).

 

/usr/bin/docker: Error response from daemon: driver failed programming external connectivity on endpoint letsencrypt (7c3343119f45bcf4276a0xxxxxxxxxf6791f5be978ae5): Bind for 0.0.0.0:443 failed: port is already allocated.

 

I can't figure this one out! Any thoughts? THANKS!

Edited by kaiguy
Link to comment
17 hours ago, aptalca said:

Your problem is likely nat loopback

 

Try it on your cell phone with a cell connection. If it works, it is nat loopback

Nope still not working. I removed the container and appdata folder and tried again. I realized I can't even get to the default nginx page (before I change the default file). I just get "Site can't be reached URL took to long to respond". I'm trying to figure out if it's pfsense blocking something or nginx not working properly. I assumed pfsense is good since apache worked without issues.

 

I do see this in my pfsense logs:

 

nginx: 2018/03/23 13:22:58 [error] 33793#100135: *847 open() "/usr/local/www/sonarr" failed (2: No such file or directory), client: 1.1.1.1(changed), server: , request: "GET /sonarr HTTP/1.1", host: "website.duckdns.org(changed)"

Edited by CrashnBrn
Link to comment
41 minutes ago, CrashnBrn said:

Nope still not working. I removed the container and appdata folder and tried again. I realized I can't even get to the default nginx page (before I change the default file). I just get "Site can't be reached URL took to long to respond". I'm trying to figure out if it's pfsense blocking something or nginx not working properly. I assumed pfsense is good since apache worked without issues.

 

I do see this in my pfsense logs:

 

nginx: 2018/03/23 13:22:58 [error] 33793#100135: *847 open() "/usr/local/www/sonarr" failed (2: No such file or directory), client: 1.1.1.1(changed), server: , request: "GET /sonarr HTTP/1.1", host: "website.duckdns.org(changed)"

 

Post your docker log

Link to comment
29 minutes ago, aptalca said:

 

Post your docker log

Here you go. I removed my email and site. The container is currently stopped. Thanks

 

[s6-init] making user provided files available at /var/run/s6/etc...exited 0.
[s6-init] ensuring user provided files have correct perms...exited 0.
[fix-attrs.d] applying ownership & permissions fixes...
[fix-attrs.d] done.
[cont-init.d] executing container initialization scripts...
[cont-init.d] 10-adduser: executing...

-------------------------------------
_ ()
| | ___ _ __
| | / __| | | / \
| | \__ \ | | | () |
|_| |___/ |_| \__/


Brought to you by linuxserver.io
We gratefully accept donations at:
https://www.linuxserver.io/donations/
-------------------------------------
GID/UID
-------------------------------------

User uid: 99
User gid: 100
-------------------------------------

[cont-init.d] 10-adduser: exited 0.
[cont-init.d] 20-config: executing...
[cont-init.d] 20-config: exited 0.
[cont-init.d] 30-keygen: executing...
generating self-signed keys in /config/keys, you can replace these with your own keys if required
Generating a 2048 bit RSA private key
........................+++
...............................................................................+++
writing new private key to '/config/keys/cert.key'
-----
[cont-init.d] 30-keygen: exited 0.
[cont-init.d] 50-config: executing...
Variables set:
PUID=99
PGID=100
TZ=America/Los_Angeles
URL=duckdns.org
SUBDOMAINS=mywebsite
EXTRA_DOMAINS=
ONLY_SUBDOMAINS=true
DHLEVEL=2048
VALIDATION=http
DNSPLUGIN=
EMAIL=myemail
STAGING=

Created donoteditthisfile.conf
Backwards compatibility check. . .
No compatibility action needed
Creating DH parameters for additional security. This may take a very long time. There will be another message once this process is completed
Generating DH parameters, 2048 bit long safe prime, generator 2
This is going to take a long time
................................................................................+...............................+........................+..............+.....................................................................................................................................................................................................................................................................................................................................................................................++*++*
DH parameters successfully created - 2048 bits
SUBDOMAINS entered, processing
SUBDOMAINS entered, processing
Only subdomains, no URL in cert
Sub-domains processed are: -d mywebsite.duckdns.org
E-mail address entered: myemail
http validation is selected
Generating new certificate
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator standalone, Installer None
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for mywebsite.duckdns.org
Waiting for verification...
Cleaning up challenges
IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/mywebsite.duckdns.org/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/mywebsite.duckdns.org/privkey.pem
Your cert will expire on 2018-06-23. To obtain a new or tweaked
version of this certificate in the future, simply run certbot

again. To non-interactively renew *all* of your certificates, run
"certbot renew"
- Your account credentials have been saved in your Certbot
configuration directory at /etc/letsencrypt. You should make a
secure backup of this folder now. This configuration directory will
also contain certificates and private keys obtained by Certbot so
making regular backups of this folder is ideal.
- If you like Certbot, please consider supporting our work by:

Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
Donating to EFF: https://eff.org/donate-le

[cont-init.d] 50-config: exited 0.
[cont-init.d] done.
[services.d] starting services
[services.d] done.
Server ready
Signal handled: Terminated.
[cont-finish.d] executing container finish scripts...
[cont-finish.d] done.
[s6-finish] syncing disks.

 

Edited by CrashnBrn
Link to comment
1 hour ago, CrashnBrn said:

Here you go. I removed my email and site. The container is currently stopped. Thanks

 


[s6-init] making user provided files available at /var/run/s6/etc...exited 0.
[s6-init] ensuring user provided files have correct perms...exited 0.
[fix-attrs.d] applying ownership & permissions fixes...
[fix-attrs.d] done.
[cont-init.d] executing container initialization scripts...
[cont-init.d] 10-adduser: executing...

-------------------------------------
_ ()
| | ___ _ __
| | / __| | | / \
| | \__ \ | | | () |
|_| |___/ |_| \__/


Brought to you by linuxserver.io
We gratefully accept donations at:
https://www.linuxserver.io/donations/
-------------------------------------
GID/UID
-------------------------------------

User uid: 99
User gid: 100
-------------------------------------

[cont-init.d] 10-adduser: exited 0.
[cont-init.d] 20-config: executing...
[cont-init.d] 20-config: exited 0.
[cont-init.d] 30-keygen: executing...
generating self-signed keys in /config/keys, you can replace these with your own keys if required
Generating a 2048 bit RSA private key
........................+++
...............................................................................+++
writing new private key to '/config/keys/cert.key'
-----
[cont-init.d] 30-keygen: exited 0.
[cont-init.d] 50-config: executing...
Variables set:
PUID=99
PGID=100
TZ=America/Los_Angeles
URL=duckdns.org
SUBDOMAINS=mywebsite
EXTRA_DOMAINS=
ONLY_SUBDOMAINS=true
DHLEVEL=2048
VALIDATION=http
DNSPLUGIN=
EMAIL=myemail
STAGING=

Created donoteditthisfile.conf
Backwards compatibility check. . .
No compatibility action needed
Creating DH parameters for additional security. This may take a very long time. There will be another message once this process is completed
Generating DH parameters, 2048 bit long safe prime, generator 2
This is going to take a long time
................................................................................+...............................+........................+..............+.....................................................................................................................................................................................................................................................................................................................................................................................++*++*
DH parameters successfully created - 2048 bits
SUBDOMAINS entered, processing
SUBDOMAINS entered, processing
Only subdomains, no URL in cert
Sub-domains processed are: -d mywebsite.duckdns.org
E-mail address entered: myemail
http validation is selected
Generating new certificate
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator standalone, Installer None
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for mywebsite.duckdns.org
Waiting for verification...
Cleaning up challenges
IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/mywebsite.duckdns.org/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/mywebsite.duckdns.org/privkey.pem
Your cert will expire on 2018-06-23. To obtain a new or tweaked
version of this certificate in the future, simply run certbot

again. To non-interactively renew *all* of your certificates, run
"certbot renew"
- Your account credentials have been saved in your Certbot
configuration directory at /etc/letsencrypt. You should make a
secure backup of this folder now. This configuration directory will
also contain certificates and private keys obtained by Certbot so
making regular backups of this folder is ideal.
- If you like Certbot, please consider supporting our work by:

Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
Donating to EFF: https://eff.org/donate-le

[cont-init.d] 50-config: exited 0.
[cont-init.d] done.
[services.d] starting services
[services.d] done.
Server ready
Signal handled: Terminated.
[cont-finish.d] executing container finish scripts...
[cont-finish.d] done.
[s6-finish] syncing disks.

 

 

Now with the default site config, go to https://yoursubdomain.duckdns.org on your mobile device on 4g/3g connection. 

 

But you need to clear your cache first because you had a 301 redirect before, which is cached permanently. Or do it on a new device if you can (or ask a friend to do it). You should get the default homepage. 

 

PS. Don't do 301 redirects unless you're sure you'll stick with it. Do a 302, it's a temporary redirect. 

 

 

  • Like 1
Link to comment
4 hours ago, aptalca said:

 

Now with the default site config, go to https://yoursubdomain.duckdns.org on your mobile device on 4g/3g connection. 

 

But you need to clear your cache first because you had a 301 redirect before, which is cached permanently. Or do it on a new device if you can (or ask a friend to do it). You should get the default homepage. 

 

PS. Don't do 301 redirects unless you're sure you'll stick with it. Do a 302, it's a temporary redirect. 

 

 

You're 100% correct! I enabled NAT reflection, changed it to a 302 redirect, cleared all my cache and everything started working!

 

Thanks for your help aptalca!

 

Edit: Any danger of leaving NAT reflection on?

Edited by CrashnBrn
Link to comment
8 hours ago, kaiguy said:

I'm suddenly running into a problem where it appears LetsEncrypt container won't load because 443 is already in use. But I don't even have SSL enabled on my server, and prior to disabling, I sent the HTTPS port to 444. No changes to my server config, but I did have an unclean shutdown and am having a parity check (but that really shouldn't have any effect).

 


/usr/bin/docker: Error response from daemon: driver failed programming external connectivity on endpoint letsencrypt (7c3343119f45bcf4276a0xxxxxxxxxf6791f5be978ae5): Bind for 0.0.0.0:443 failed: port is already allocated.

 

I can't figure this one out! Any thoughts? THANKS!

netstat -nptl

(I believe it's in nerd tools) should show you what's listening on that port

Edited by psm321
add -n to show port numbers
Link to comment
2 hours ago, CrashnBrn said:

You're 100% correct! I enabled NAT reflection, changed it to a 302 redirect, cleared all my cache and everything started working!

 

Thanks for your help aptalca!

 

Edit: Any danger of leaving NAT reflection on?

 

None that I know of. I use split dns but either should be fine: https://doc.pfsense.org/index.php/Why_can't_I_access_forwarded_ports_on_my_WAN_IP_from_my_LAN/OPTx_networks

Link to comment
10 hours ago, psm321 said:

netstat -nptl

(I believe it's in nerd tools) should show you what's listening on that port

Thanks for this!

 

The only reference to port 443 I could find was:

 

tcp6    0   0 :::443          :::*         LISTEN      5814/docker-proxy

Which I believe would be the LE container. Not sure why it won't let me start the container with 443... especially since it's been working fine for months.

Link to comment
4 hours ago, kaiguy said:

Thanks for this!

 

The only reference to port 443 I could find was:

 


tcp6    0   0 :::443          :::*         LISTEN      5814/docker-proxy

Which I believe would be the LE container. Not sure why it won't let me start the container with 443... especially since it's been working fine for months.

 

Perhaps it's running and unRAID lost track of it?  (not sure if that's possible, I'm new to all this).

 

docker ps | grep "0.0.0.0:443"

should tell you what container is using it

Link to comment

I installed the letsencrypt docker,  Set it up based on suggestions here, but when it starts I get an "Execution Error".   Go to look at logs and there is nothing there.  Then go to look at the appdata folder and see that it is empty.  Double checked that I set the location right.  So I remove the docker and reinstall, same results - execution error and nothing in the appdata folder.  I tried changing the name, same thing.  What am I missing?   Would a server restart fix this?

Link to comment
3 hours ago, shalvers said:

I installed the letsencrypt docker,  Set it up based on suggestions here, but when it starts I get an "Execution Error".   Go to look at logs and there is nothing there.  Then go to look at the appdata folder and see that it is empty.  Double checked that I set the location right.  So I remove the docker and reinstall, same results - execution error and nothing in the appdata folder.  I tried changing the name, same thing.  What am I missing?   Would a server restart fix this?

 

Not easy to say when we don't have any info. At least post screenshots of the container template. 

Link to comment
4 hours ago, shalvers said:

I installed the letsencrypt docker,  Set it up based on suggestions here, but when it starts I get an "Execution Error".   Go to look at logs and there is nothing there.  Then go to look at the appdata folder and see that it is empty.  Double checked that I set the location right.  So I remove the docker and reinstall, same results - execution error and nothing in the appdata folder.  I tried changing the name, same thing.  What am I missing?   Would a server restart fix this?

https://lime-technology.com/forums/topic/57181-real-docker-faq/#comment-564345

 

Link to comment

Here is the run command:

 

root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name="letsencrypt" --net="bridge" --privileged="true" -e TZ="America/New_York" -e HOST_OS="unRAID" -e "EMAIL"="[email protected]" -e "URL"="mysite.com" -e "SUBDOMAINS"="www" -e "ONLY_SUBDOMAINS"="false" -e "DHLEVEL"="2048" -e "VALIDATION"="http" -e "DNSPLUGIN"="" -e "PUID"="99" -e "PGID"="100" -p 80:80/tcp -p 443:443/tcp -v "/mnt/user/appdata/letsencrypt":"/config":rw linuxserver/letsencrypt
d0a1c030ebb3f2bf21c3446242886f152b846506c8cedd71277d36973476b18e

 

I don't understand this:

image.png.e1a001260225dbe035a87abaa23c44a2.png

Link to comment

I'm having trouble with a wildcard certificate. I've got letsencrypt running through docker-compose, and prior to now have been using a certificate for specific subdomains which has been working perfectly. Today I have been trying to get it to work with a single wildcard certificate instead.

 

In the letsencrypt log is says:

...
Waiting 30 seconds for DNS changes to propagate
Waiting for verification...
Cleaning up challenges
An unexpected error occurred:
Exception: Record identifier could not be found.
Please see the logfiles in /var/log/letsencrypt for more details.
IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: [domain].im
   Type: unauthorized
   Detail: Incorrrect TXT record
   "cR1VRcO[...]WwIKF4yJiqV-eQ" found at
   _acme-challenge.<domain>.im
   ...

So I guess for some reason the wrong TXT record is getting set?

 

When I repeat the process (again trying to use a wildcard), it finds the same wrong TXT record. If I change it back to particular subdomains, everything works as intended (and that same wrong TXT record is not the one that is used).

 

I'm using nsone.net (which is the only one supported for DNS challenges that is both free and lets you use wildcard subdomains in the dns as far as I could see).

 

The pertinent part of my docker-compose is:

 

linuxserver-letsencrypt:
    image: linuxserver/letsencrypt
    container_name: linuxserver-letsencrypt
    restart: unless-stopped
    ports:
      - 443:443
      - 80:80
    environment:
      - TZ=America/Chicago
      - PGID=${PGID}
      - PUID=${PUID}
      - EMAIL=<email>
      - URL=<domain>.im
      - VALIDATION=dns
      - DNSPLUGIN=nsone
      - SUBDOMAINS=wildcard
    volumes:
      - /opt/appdata/linuxserver-letsencrypt:/config
    cap_add:
      - NET_ADMIN

 

I read something above about a problem with letsencrypt and some other newer TLD. I'm using "im" TLD. Maybe this is part of the problem? But it works find if I'm doing it with specific domains/subdomains, and only fails with wildcard.

 

I exec'd into the docker and had a look at /var/log/letsencrypt/letsencrypt.log. It's pretty long and I'm not sure what I'm looking for to diagnose this. I see at the end where it lists the same incorrect TXT record being found when it does the acme-challenge. Maybe there is something in this file that would be helpful to help figure out why this is failing?

Edited by fivestones
updated output of logfile
Link to comment
1 hour ago, shalvers said:

Here is the run command:

 

root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name="letsencrypt" --net="bridge" --privileged="true" -e TZ="America/New_York" -e HOST_OS="unRAID" -e "EMAIL"="[email protected]" -e "URL"="mysite.com" -e "SUBDOMAINS"="www" -e "ONLY_SUBDOMAINS"="false" -e "DHLEVEL"="2048" -e "VALIDATION"="http" -e "DNSPLUGIN"="" -e "PUID"="99" -e "PGID"="100" -p 80:80/tcp -p 443:443/tcp -v "/mnt/user/appdata/letsencrypt":"/config":rw linuxserver/letsencrypt
d0a1c030ebb3f2bf21c3446242886f152b846506c8cedd71277d36973476b18e

 

I don't understand this:

image.png.e1a001260225dbe035a87abaa23c44a2.png

 

You try to run on the same ports as unraid uses.  You need to change the ports to something unused by unraid or other containers. 

You also need to port forward port 80 and 443 in your firewall to the new ports you choose.

Link to comment
43 minutes ago, fivestones said:

I'm having trouble with a wildcard certificate. I've got letsencrypt running through docker-compose, and prior to now have been using a certificate for specific subdomains which has been working perfectly. Today I have been trying to get it to work with a single wildcard certificate instead.

 

In the letsencrypt log is says:


...
Waiting 30 seconds for DNS changes to propagate
Waiting for verification...
Cleaning up challenges
An unexpected error occurred:
Exception: Record identifier could not be found.
Please see the logfiles in /var/log/letsencrypt for more details.
IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: [domain].im
   Type: unauthorized
   Detail: Incorrrect TXT record
   "cR1VRcO[...]WwIKF4yJiqV-eQ" found at
   _acme-challenge.<domain>.im
   ...

So I guess for some reason the wrong TXT record is getting set?

 

When I repeat the process (again trying to use a wildcard), it finds the same wrong TXT record. If I change it back to particular subdomains, everything works as intended (and that same wrong TXT record is not the one that is used).

 

I'm using nsone.net (which is the only one supported for DNS challenges that is both free and lets you use wildcard subdomains in the dns as far as I could see).

 

The pertinent part of my docker-compose is:

 


linuxserver-letsencrypt:
    image: linuxserver/letsencrypt
    container_name: linuxserver-letsencrypt
    restart: unless-stopped
    ports:
      - 443:443
      - 80:80
    environment:
      - TZ=America/Chicago
      - PGID=${PGID}
      - PUID=${PUID}
      - EMAIL=<email>
      - URL=<domain>.im
      - VALIDATION=dns
      - DNSPLUGIN=nsone
      - SUBDOMAINS=wildcard
    volumes:
      - /opt/appdata/linuxserver-letsencrypt:/config
    cap_add:
      - NET_ADMIN

 

I read something above about a problem with letsencrypt and some other newer TLD. I'm using "im" TLD. Maybe this is part of the problem? But it works find if I'm doing it with specific domains/subdomains, and only fails with wildcard.

 

I exec'd into the docker and had a look at /var/log/letsencrypt/letsencrypt.log. It's pretty long and I'm not sure what I'm looking for to diagnose this. I see at the end where it lists the same incorrect TXT record being found when it does the acme-challenge. Maybe there is something in this file that would be helpful to help figure out why this is failing?

 

Perhaps there is a problem with the api info you entered. Not sure. You can try deleting that existing wrong txt record from your dns

 

I use cloudflare, which is also free and supports wildcard

Link to comment
1 hour ago, fivestones said:

I read something above about a problem with letsencrypt and some other newer TLD. I'm using "im" TLD. Maybe this is part of the problem? But it works find if I'm doing it with specific domains/subdomains, and only fails with wildcard.

 

I exec'd into the docker and had a look at /var/log/letsencrypt/letsencrypt.log. It's pretty long and I'm not sure what I'm looking for to diagnose this. I see at the end where it lists the same incorrect TXT record being found when it does the acme-challenge. Maybe there is something in this file that would be helpful to help figure out why this is failing?

I would personally suggest trying a longer propogate delay.  I was having similar issues with 30 seconds.  Unfortunately AFAIK there's not a container variable for this -- I ended up editing something inside the container.

Link to comment
3 hours ago, psm321 said:

I would personally suggest trying a longer propogate delay.  I was having similar issues with 30 seconds.  Unfortunately AFAIK there's not a container variable for this -- I ended up editing something inside the container.

 

Please correct me if I'm wrong, but I believe that is hardcoded into the dns plugins. Not sure if the plugins provide any options to be entered into the cfg files.

 

The documentation for certbot and the plugins is pretty awful. I had to go through the source code to figure out the wildcard options

Link to comment
53 minutes ago, aptalca said:

 

Please correct me if I'm wrong, but I believe that is hardcoded into the dns plugins. Not sure if the plugins provide any options to be entered into the cfg files.

 

The documentation for certbot and the plugins is pretty awful. I had to go through the source code to figure out the wildcard options

I'm on my phone so I didn't check all of them, but at least some of the plugins have an individual option for it.  The one I used has it and so does the nsone one.

 

https://certbot-dns-rfc2136.readthedocs.io/en/latest/

 

https://certbot.eff.org/docs/using.html#dns-plugins

 

err, command-line options, not config file options afaict.  That would be too convenient :)

Edited by psm321
Clarify
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.