The Bitmessage protocol v3 became mandatory on 16 Nov 2014 and notbit does not support it, nor has there been any activity in the project repository since then.
This module implements a way to start one or more bepasty servers.
It supports configuring the listen address of gunicorn and how bepasty
behaves internally.
Configuring multiple bepasty servers provides a way to serve pastes externally
without authentication and provide creating,listing,deleting pastes interally.
nginx can be used to provide access via hostname + listen address.
`configuration.nix`:
services.bepasty = {
enable = true;
servers = {
internal = {
defaultPermissions = "admin,list,create,read,delete";
secretKey = "secret";
bind = "127.0.0.1:8000";
};
external = {
defaultPermissions = "read";
bind = "127.0.0.1:8001";
secretKey = "another-secret";
};
};
};
These services don't create files on disk, let alone on a network
filesystem, so they don't really need a fixed uid. And this also gets
rid of a warning coming from <= 14.12 systems.
This updates rdnssd to the following:
* Using the systemd interfaces directly
* Using the rdnssd user instead of the root user
* Integrating with resolvconf instead of writing directly to /etc/resolv.conf
This patch resolves all uid/gid conflicts except for nobody/nogroup (seems
to make sense that these are the same).
All conflicts where determined mechanically, but resolutions were manual.
This patch also marks uids/gids with no corresponding group/user as "unused"
(aka. reserved).
Briefly,
- tss group conflicts with dhcpcd
The tss group id conflicts with dhcpcd: assign
a new number and add a corresponding tss user.
- elasticsearch uid conflicts with haproxy gid
- resolve firebird/munin conflict
- fix fourstorehttp{,d} typo
- fix ghostOne typo: the service module refers to gids.ghostone, so use that
in ids
- memcached uid conflicts with users gid
- nagios uid conflicts with disks gid
- nscd uid conflicts with wheel gid
- ntp uid conflicts with tty gid
- resolve postfix/postdrop id uid
- redis uid conflicts with keys gid
- sshd uid conflicts with kmem gid
- tcryptd uid conflicts with openldap gid
- unifi uid conflicts with docker gid
- uptimed uid conflicts with utmp gid
- zope2 uid conflicts with connman gid
- tomcat uid/gid mismatch
I had to make several adjustments to make it work with nixos:
* Replace relative config file lookups with ENV variable.
* Modify gitlab-shell to not clear then environment when running
pre-receive.
* Modify gitlab-shell to write some environment variables into
the .authorized_keys file to make sure gitlab-shell reads the
correct config file.
* Log unicorn output to syslog.
I tried various ways of adding a syslog package but the bundler would
not pick them up. Please fix in a better way if possible.
* Gitlab-runner program wrapper.
This is useful to run e.g. backups etc. with the correct
environment set up.
This overhauls the Tor module in a few ways:
- Uses systemd service files, including hardening/config checks
- Removed old privoxy support; users should use the Tor Browser
instead.
- Remove 'fast' circuit/SOCKS port; most users don't care (and it adds
added complexity and confusion)
- Added support for bandwidth accounting
- Removed old relay listenAddress option; taken over by portSpec
- Formatting, description, code cleanups.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
The dnscrypt-proxy service relays regular DNS queries to
a DNSCrypt enabled upstream resolver.
The traffic between the client and the upstream resolver is
encrypted and authenticated, which may mitigate the risk of
MITM attacks and third-party snooping (assuming a trustworthy
upstream).
Though dnscrypt-proxy can run as a standalone DNS client,
the recommended setup is to use it as a forwarder for a
caching DNS client.
To use dnscrypt-proxy as a forwarder for dnsmasq, do
```nix
{
# ...
networking.nameservers = [ "127.0.0.1" ];
networking.dhcpcd.extraConfig = "nohook resolv.conf";
services.dnscrypt-proxy.enable = true;
services.dnscrypt-proxy.localAddress = "127.0.0.1";
services.dnscrypt-proxy.port = 40;
services.dnsmasq.enable = true;
services.dnsmasq.extraConfig = ''
no-resolv
server=127.0.0.1#40
listen-address=127.0.0.1
'';
# ...
}
```
It's not that difficult to define shares using standard samba config
file syntax, so why do we need the semi-configurable .defaultShare
option?
Also:
* It uses /home/smbd and I think /home should be reserved
for real human users.
* If enabled, it breaks the assumption that .extraConfig continues in
the [global] section.
Without .defaultShare there is no need for the "smbguest" user and group
either, mark them as unused.
