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.
* The module now has systemd config
* Add resolveLocalQueries option which sets up it as a dns server for
local host (including reasonable setup of resolvconf)
* Add "dnsmasq" user for running daemon
* Enabled dbus and dnssec support for the package
Conflicts:
nixos/modules/misc/ids.nix
Additionally, remove the automatic initialization of the ipv6 forwarding
sysctl as this should be handled by the end user. This really should not
be an issue as most people running radvd are likely forwarding ipv6
packets.
This version of module has disabled socketActivation, because until
nixos upgrade systemd to at least 214, systemd does not support
SocketGroup. So socket is created with "root" group when
socketActivation enabled. Should be fixed as soon as systemd upgraded.
Includes changes from #3015 and supersedes #3028
This overhauls the Datadog module a bit to be much more useful. In
particular, it adds support for nginx and postgresql monitoring
integrations to dd-agent. These have to exist in separate files under
/etc/dd-agent, so the module just exposes then as separate options. In
the future, more integrations could be added this way.
In the process of doing this, I also had to rename the dd-agent user to
datadog. Note the UIDs did not change, so this is strictly backwards
compatible. The reason for this is to make it easier to create a
'datadog' postgres user with access to pg_stats, as 'dd-agent' typically
isn't a valid username. This allows the out of the box configurations to
be used.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
The style for IDs dictates that groups/users should have the same ID -
so if a user doesn't have a group or vice versa, then we should skip
that ID.
In this case, we had already assigned grsecurity GID 121, but I
accidentally also assigned Hydra UID 121. Instead, let's assign Hydra
UID 122. And also assign a GID (122) as well.
Luckily nobody was depending on this yet (except me).
Signed-off-by: Austin Seipp <aseipp@pobox.com>
This module implements a significant refactoring in grsecurity
configuration for NixOS, making it far more usable by default and much
easier to configure.
- New security.grsecurity NixOS attributes.
- All grsec kernels supported
- Allows default 'auto' grsec configuration, or custom config
- Supports custom kernel options through kernelExtraConfig
- Defaults to high-security - user must choose kernel, server/desktop
mode, and any virtualisation software. That's all.
- kptr_restrict is fixed under grsecurity (it's unwriteable)
- grsecurity patch creation is now significantly abstracted
- only need revision, version, and SHA1
- kernel version requirements are asserted for sanity
- built kernels can have the uname specify the exact grsec version
for development or bug reports. Off by default (requires
`security.grsecurity.config.verboseVersion = true;`)
- grsecurity sysctl support
- By default, disabled.
- For people who enable it, NixOS deploys a 'grsec-lock' systemd
service which runs at startup. You are expected to configure sysctl
through NixOS like you regularly would, which will occur before the
service is started. As a result, changing sysctl settings requires
a reboot.
- New default group: 'grsecurity'
- Root is a member by default
- GRKERNSEC_PROC_GID is implicitly set to the 'grsecurity' GID,
making it possible to easily add users to this group for /proc
access
- AppArmor is now automatically enabled where it wasn't before, despite
implying features.apparmor = true
The most trivial example of enabling grsecurity in your kernel is by
specifying:
security.grsecurity.enable = true;
security.grsecurity.testing = true; # testing 3.13 kernel
security.grsecurity.config.system = "desktop"; # or "server"
This specifies absolutely no virtualisation support. In general, you
probably at least want KVM host support, which is a little more work.
So:
security.grsecurity.enable = true;
security.grsecurity.stable = true; # enable stable 3.2 kernel
security.grsecurity.config = {
system = "server";
priority = "security";
virtualisationConfig = "host";
virtualisationSoftware = "kvm";
hardwareVirtualisation = true;
}
This module has primarily been tested on Hetzner EX40 & VQ7 servers
using NixOps.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
By default the jenkins server is executed under the user "jenkins". Which can be configured using
users.jenkins.* options. If a different user is requested by changing services.jenkins.user then
none of the users.jenkins options apply.
This patch does not include jenkins slave configuration. Some config options will probably change
when this is implemented.
Aspects like the user and environment are typically identical between slave and master. The service
configs are different. The design is for users.jenkins to cover the shared aspects while
services.jenkins and services.jenkins-slave cover the master and slave specific aspects,
respectively.
Another option would be to place everything under services.jenkins and have a config that selects
master vs slave.
