The shairport-sync service currently fails to start with the error
shairport avahi_entry_group_new failed
This problem seems to have been introduced by
cdd7310a50
After some trial and error I concluded that the attached commit is a minimal
fix.
stripHash uses a global variable to communicate it's computation
results, but it's not necessary. You can just pipe to stdout in a
subshell. A function mostly behaves like just another command.
baseHash() also introduces a suffix-stripping capability since it's
something the users of the function tend to use.
wpa_supplicant fails to start if the wireless interfaces aren't ready yet,
so we need to add a system ordering directive here to start wpa_supplicant
after the interfaces are ready. Note that Requires= is not enough since
it does not imply ordering.
The update-resolve-conf script from the update-resolv-conf
package is very useful and should work in most of the common
cases, so this adds an option to enable it. The option is
disabled by default for backwards compatibility.
This reverts commit c25907d072.
I think this commit broke the NixOS service for NetworkManager. At least
with this, and the two previous reverts, everything is back to normal.
(With multiple-outputs split, it would have reduced the closure size by
3 MiB.)
This reverts commit 7ac1ef05fa.
One of a few reverts needed to unbreak networkmanager NixOS service
since the multiple-output split (to save 3 MiB of closure size).
This reverts commit 2875293615.
One of a few reverts needed to unbreak networkmanager NixOS service
since the multiple-output split (to save 3 MiB of closure size).
leveraging users.users.<user>.createHome instead of a preStart script.
preStart script is still required to ensure proper creation of logging
directory.
The list of public proxies is updated now and again and it's probably a
good idea to always work from the most recent list, rather than the one
that is shipped with the release. This can be crucial in case of
resolvers that are revealed to have gone rogue or otherwise have been
compromised.
- services.iodined moved to services.iodine
- configuration file backwards compatable
- old iodine server configuration moved to services.iodine.server
- attribute set services.iodine.clients added to specify any number
of iodine clients
- example:
iodine.clients.home = { server = "iodinesubdomain.yourserver.com"; ... };
- client services names iodine-name where name would be home
Previously, the cisco resolver was used on the theory that it would
provide the best user experience regardless of location. The downsides
of cisco are 1) logging; 2) missing supoprt for DNS security extensions.
The new upstream resolver is located in Holland, supports DNS security,
and *claims* to not log activity. For users outside of Europe, this will
mean reduced performance, but I believe it's a worthy tradeoff.
When iodined tries to start before any interface other than loopback has an ip, iodined fails.
Wait for ip-up.target
The above is because of the following:
in iodined's code: src/common.c line 157
the flag AI_ADDRCONFIG is passed as a flag to getaddrinfo.
Iodine uses the function
get_addr(char *host,
int port,
int addr_family,
int flags,
struct sockaddr_storage *out);
to get address information via getaddrinfo().
Within get_addr, the flag AI_ADDRCONFIG is forced.
What this flag does, is cause getaddrinfo to return
"Name or service not known" as an error explicitly if no ip
has been assigned to the computer.
see getaddrinfo(3)
Wait for an ip before starting iodined.
This patch fixes https://github.com/NixOS/nixpkgs/issues/12927.
It would be great to configure good rate-limiting defaults for this via
/proc/sys/net/ipv4/icmp_ratelimit and /proc/sys/net/ipv6/icmp/ratelimit,
too, but I didn't since I don't know what a "good default" would be.
Some users may wish to improve their privacy by using per-query
key pairs, which makes it more difficult for upstream resolvers to
track users across IP addresses.
- fix `enable` option description
using `mkEnableOption longDescription` is incorrect; override
`description` instead
- additional details for proper usage of the service, including
an example of the recommended configuration
- clarify `localAddress` option description
- clarify `localPort` option description
- clarify `customResolver` option description
