riak-cs: added to all-packages
Added Riak CS nix file to pkgs
Added service file for Riak CS
Removed Erlang_basho specific bindings from the Riak CS repo
riak-cs: changed description
riak-cs: added license
riak-cs: added maintainer
riak_cs: chgned indentations
riak-cs: removed overly complex srcs mechanism
riak-cs: added systemd module
riak-cs: changed Erlang module to Basho-specific version
riak-cs: made modular form
riak-cs: Added a default package in service options
riak-cs: Fixed default package in service options
riak-cs: Patched Makefile
riak_cs: added to module-list
riak_cs: changed from string to actual package in modules
riak-cs: changed example
riak-cs: removed default
riak-cs: changed to defaultText
stanchion: changed default option to defaultText
riak-cs: added defaults; changed types to str
Let's first try if we can determine the Git revision from the .git
directory and if that fails, fall back to get the info from the
".git-revision" file... and after that use something generic like
"master".
This should address #17218 in better way, because we don't need to
create another redundant file in the source checkout of nixpkgs.
I'm not going to route of falling back to using .git, because after
55d881e, we already have ".git-revision" files in people's Git
repositories, which in turn means that nixos-version will report that
old file every time even if the working tree has updated.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @bennofs, Profpatsch
Reported-by: @devhell
Fixes: #17218
GoCD is an open source continuous delivery server specializing in advanced workflow
modeling and visualization. Update maintainers list to include swarren83. Update
module list to include gocd agent and server module. Update packages list to include
gocd agent and server package. Update version, revision and checksum for GoCD
release 16.5.0.
This GID was used to exempt users from Grsecurity's
`/proc` restrictions; we now prefer to rely on
`security.hideProcessInformation`, which uses the `proc` group
for this purpose. That leaves no use for the grsecurity GID.
More generally, having only a single GID to, presumably, serve as the
default for all of grsecurity's GID based exemption/resriction schemes
would be problematic in any event, so if we decide to enable those
grsecurity features in the future, more specific GIDs should be added.
This adds a Taskserver module along with documentation and a small
helper tool which eases managing a custom CA along with Taskserver
organisations, users and groups.
Taskserver is the server component of Taskwarrior, a TODO list
application for the command line.
The work has been started by @matthiasbeyer back in mid 2015 and I have
continued to work on it recently, so this merge contains commits from
both of us.
Thanks particularly to @nbp and @matthiasbeyer for reviewing and
suggesting improvements.
I've tested this with the new test (nixos/tests/taskserver.nix) this
branch adds and it fails because of the changes introduced by the
closure-size branch, so we need to do additional work on base of this.
It was failing with a `Read-only filesystem` failure due to the systemd
service option `ReadWriteDirectories` not being correctly configured.
Fixes#14132
This module adds an option `security.hideProcessInformation` that, when
enabled, restricts access to process information such as command-line
arguments to the process owner. The module adds a static group "proc"
whose members are exempt from process information hiding.
Ideally, this feature would be implemented by simply adding the
appropriate mount options to `fileSystems."/proc".fsOptions`, but this
was found to not work in vmtests. To ensure that process information
hiding is enforced, we use a systemd service unit that remounts `/proc`
after `systemd-remount-fs.service` has completed.
To verify the correctness of the feature, simple tests were added to
nixos/tests/misc: the test ensures that unprivileged users cannot see
process information owned by another user, while members of "proc" CAN.
Thanks to @abbradar for feedback and suggestions.
I'm renaming the attribute name for uid, because the user name is called
"taskd" so we should really use the same name for it.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
hydra user is already pinned, this is needed due to
https://github.com/NixOS/nixpkgs/issues/14148
(cherry picked from commit 0858ece1ad0bd281d2332c40f9fd08005e04a3c5)
Signed-off-by: Domen Kožar <domen@dev.si>
- Enforce that an option declaration has a "defaultText" if and only if the
type of the option derives from "package", "packageSet" or "nixpkgsConfig"
and if a "default" attribute is defined.
- Enforce that the value of the "example" attribute is wrapped with "literalExample"
if the type of the option derives from "package", "packageSet" or "nixpkgsConfig".
- Warn if a "defaultText" is defined in an option declaration if the type of
the option does not derive from "package", "packageSet" or "nixpkgsConfig".
- Warn if no "type" is defined in an option declaration.
NetworkManager needs an additional avahi-user to use link-local
IPv4 (and probably IPv6) addresses. avahi-autoipd also needs to be
patched to the right path.
- add missing types in module definitions
- add missing 'defaultText' in module definitions
- wrap example with 'literalExample' where necessary in module definitions
Setting nixosVersion to something custom is useful for meaningful GRUB
menus and /nix/store paths, but actuallly changing it rebulids the
whole system path (because of `nixos-version` script and manual
pages). Also, changing it is not a particularly good idea because you
can then be differentitated from other NixOS users by a lot of
programs that read /etc/os-release.
This patch introduces an alternative option that does all you want
from nixosVersion, but rebuilds only the very top system level and
/etc while using your label in the names of system /nix/store paths,
GRUB and other boot loaders' menus, getty greetings and so on.
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";
};
};
};
This option requests compatibility with older NixOS releases with
respect to stateful data, in cases where new releases have defaults
that might be incompatible with system state of existing NixOS
deployments. For instance, if we change the default version of
PostgreSQL, existing deployments will break if the new version can't
read databases created by the old version.
So for example, setting
system.stateVersion = "15.07";
requests that options like services.postgresql.package use defaults
corresponding to the 15.07 release branch. Note that
nixos-generate-config emits this option. (In the future, NixOps may
set system.stateVersion to the NixOS release in use when the machine
was created.)
See also #7939 for another motivating example.
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
'';
# ...
}
```
