| Age | Commit message (Collapse) | Author |
|---|
|
When tor hidden services were enabled for static sites, only a very
basic configuration was setup and it didn't take into account the
different location configurations that can be configured for a
static site.
This commit resolves that by making a site_static::hidden_service class
similar to the site_webapp::hidden_service class, and fixes up the
apache vhost template to properly create the location blocks for the
hidden service vhost.
Change-Id: Ice3586f4173bd2d1bd3defca29d21c7403d5a03a
|
|
We were creating the hidden service name without a newline, and then tor
would be restarted and change the hidden service hostname file to have a
newline, which would then require that the next deploy would change that
file to not have a newline again.
This fixes that problem by making the hostname have a newline so it
matches what tor wants.
Change-Id: I38f450684d557cf943ec94f2f8e19cda3aefdf66
|
|
Change-Id: I3d733b6645c804a5fb337ad4b8edc59a66ad50b5
|
|
Change-Id: Icaab817870d005b7a854a3fb8c402705d0b2d77f
|
|
|
|
|
|
Will try later, but for now it fails with not finding bundle cmd.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Change-Id: Iab9597f5f0336f66df9b73fea9d79c789cbb8302
|
|
|
|
|
|
|
|
The Trace method is enabled because of the Apache module, but it is not the
default in Debian, and it should not be enabled, for more information see the
following:
https://www.kb.cert.org/vuls/id/867593
Change-Id: I06a06ae679dbf7049f26a017125b61e5e38f6268
|
|
The onlyif check was incorrectly specified in the original implementation in
commit id: 15b83d88dcedab496a19cef57f11c5c8e091dd4a this inverts it so it
is properly detected.
Change-Id: I531e206fff1ca61780adcd195e1f917011e50fb4
|
|
The Trace method is enabled because of the Apache module, but it is not the
default in Debian, and it should not be enabled, for more information see the
following:
https://www.kb.cert.org/vuls/id/867593
Change-Id: I06a06ae679dbf7049f26a017125b61e5e38f6268
|
|
The onlyif check was incorrectly specified in the original implementation in
commit id: 15b83d88dcedab496a19cef57f11c5c8e091dd4a this inverts it so it
is properly detected.
Change-Id: I531e206fff1ca61780adcd195e1f917011e50fb4
|
|
Change-Id: Ic12b243b195e40482a70dd70219212c3697899ba
|
|
Change-Id: I772c3b6e489e3c1848c45c6bcaa240324fc88928
|
|
|
|
Change-Id: I7675dbaba4d896a62dab9fcf4817092ea69f1298
|
|
It turns out that in some corner-cases, the script is not called:
(1) start the deploy, create files in /var/lib/puppet/stunnel4/config
(2) halt puppet before apply finishes
(3) re-run deploy
in this scenario, next time you run deploy, refresh_stunnel will never
get called to populate /etc/stunnel, because the files in
/var/lib/puppet/stunnel4/config haven't changed.
This problem can be really confusing when it happens.
To fix this, we just run refresh_stunnel every, it is pretty fast and
the script has more complete logic for what to do than puppet, which has
only an asymmetrical view on the situation.
Change-Id: I9e5fad1d081c2fe07f3ac8f07cfb87d86b88f7c9
|
|
|
|
|
|
if this is set in the config, the deamons do not
start anymore. From the debian changelog:
clamav (0.99.2+dfsg-0+deb8u1) stable; urgency=medium
* Import new Upstream.
* Drop AllowSupplementaryGroups option which is default now
(Closes: #822444).
|
|
The unix socket method for connecting to the milter was incorrectly
reverted, this puts it back to how it should be.
Change-Id: Ifde669c920a249c782f577a112f4d45e60a889a2
|
|
|
|
The agent wakes up every two minutes and tries to connect to the default
server, failing with a certificate warning. We don't use the agent, so
we can safely disable it (#8032)
Change-Id: I707f42b59205993325431aba283552b1b73a0ad1
|
|
check_mk operations can take a long time (such as when doing a
re-inventory using "check_mk -II") when multiple hosts are down. This
decreases the connect timeout to 5 seconds.
Change-Id: I1eac5f14bad2afc2ffc4cbf8c950c24b052a0d6e
|
|
|
|
|
|
After including everything into a `node default` scope
in puppet/manifests/site.pp to make puppet-catalog-test happy
(see commit 62ea45d47), we get this error:
Error: member(): Requires array to work with at
/srv/leap/puppet/modules/site_obfsproxy/manifests/init.pp:14
Moving the `services` hiera avaluation out of the node scope back
to top level scope will solve this.
|
|
Change-Id: Ic12b243b195e40482a70dd70219212c3697899ba
|
|
Change-Id: I772c3b6e489e3c1848c45c6bcaa240324fc88928
|
|
|
|
Change-Id: I7675dbaba4d896a62dab9fcf4817092ea69f1298
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
It turns out that in some corner-cases, the script is not called:
(1) start the deploy, create files in /var/lib/puppet/stunnel4/config
(2) halt puppet before apply finishes
(3) re-run deploy
in this scenario, next time you run deploy, refresh_stunnel will never
get called to populate /etc/stunnel, because the files in
/var/lib/puppet/stunnel4/config haven't changed.
This problem can be really confusing when it happens.
To fix this, we just run refresh_stunnel every, it is pretty fast and
the script has more complete logic for what to do than puppet, which has
only an asymmetrical view on the situation.
Change-Id: I9e5fad1d081c2fe07f3ac8f07cfb87d86b88f7c9
|
