sftdyn | Self-hosted dyndns/dynamic DNS server and updater for bind | DNS library

by SFTtech Python Version: 0.10 License: Non-SPDX

X-Ray Key Features Code Snippets Community Discussions(1)Vulnerabilities Install Support

kandi X-RAY | sftdyn Summary

sftdyn is a Python library typically used in Networking, DNS applications. sftdyn has no bugs, it has no vulnerabilities, it has build file available and it has low support. However sftdyn has a Non-SPDX License. You can install using 'pip install sftdyn' or download it from GitHub, PyPI.

This software was written after the free dyndns.org service was shut down. After a week or so of using plain nsupdate, we were annoyed enough to decide to write this. The main goal of this tool is to stay as minimal as possible; for example, we deliberately didn't implement a way to specify the hostname or IP that you want to update; just a simple secret update key is perfectly good for the intended purpose. If you feel like it, you can make the update key look like a more complex request; every character is allowed. Example: host=test.sft.mx,key=90bbd8698198ea76.

Support

Quality

Security

License

Reuse

Support

sftdyn has a low active ecosystem.

It has 171 star(s) with 36 fork(s). There are 15 watchers for this library.

It had no major release in the last 12 months.

There are 2 open issues and 9 have been closed. On average issues are closed in 146 days. There are no pull requests.

It has a neutral sentiment in the developer community.

The latest version of sftdyn is 0.10

Quality

sftdyn has 0 bugs and 0 code smells.

Security

sftdyn has no vulnerabilities reported, and its dependent libraries have no vulnerabilities reported.

sftdyn code analysis shows 0 unresolved vulnerabilities.

There are 0 security hotspots that need review.

License

sftdyn has a Non-SPDX License.

Non-SPDX licenses can be open source with a non SPDX compliant license, or non open source licenses, and you need to review them closely before use.

Reuse

sftdyn releases are not available. You will need to build from source code and install.

Deployable package is available in PyPI.

Build file is available. You can build the component from source.

Installation instructions, examples and code snippets are available.

Top functions reviewed by kandi - BETA

kandi has reviewed sftdyn and discovered the below as its top functions. This is intended to give you an instant insight into sftdyn implemented functionality, and help decide if they suit your requirements.

Parse CLI options
Return an argument parser
Convert a string to IP address
Setup logging
Clamp a number to the given number
Handle request
Handle a nsupdate request
Start listening for events

Get all kandi verified functions for this library.

sftdyn Key Features

No Key Features are available at this moment for sftdyn.

sftdyn Examples and Code Snippets

No Code Snippets are available at this moment for sftdyn.

Community Discussions

Trending Discussions on sftdyn

How to share Letsencrypt cert files amonst several daemons having different group name

QUESTION

How to share Letsencrypt cert files amonst several daemons having different group name

Asked 2018-Aug-08 at 02:29

Multiple daemon applications would like to access the same TLS certificates (or chain, or private) keys.

NGINX wants to access /etc/letsencrypt/live/example.org/privkey.pem
So does Apache.
And BIND.
And my favorite [sftdyn] Github package.

And they all run their daemon with different GID and group name.

My attempts at securing the private key in a safe manner, yet sharing it across different daemons (having their own GID) with the following various approaches (and some later nixed) are:

Set file permission to "blaze of glory" chmod a+rwx. This got nixed because it reveals the secret privkey.pem file to the entire filesystem.
Create a new group keys and add nginx, apache, named (or bind), and sftdyn group to the keys group in /etc/group (or using adduser nginx keys). Use new keys group on the PEM files. Then cap PEM files' permission with chmod 0640.
Use setfacl.

Which of 2 or 3 is best to address this thorny issue?

...

ANSWER

Answered 2018-Aug-08 at 02:29

System admin side of me believes strongly in "keep it simple" and says to do it via the "keys" group (or ssldaemons or whatever you want to name it - I think group names should describe the membership or purpose if possible) and regular old boring file system permissions.

On the other hand, if you are already using ACLs then using just another ACL rule or three would fit better into your work flow/policy/admin style.

If you aren't using ACLs already, then I wouldn't head down that road - no need to make things excessively complex. Unless of course you need an excuse to management to do it :)

Source https://stackoverflow.com/questions/51736558

Community Discussions, Code Snippets contain sources that include Stack Exchange Network

Vulnerabilities

No vulnerabilities reported

Install sftdyn

By default sftdyn uses a key auto-generated by bind, /var/run/named/session.key. The permissions of this file may be reset on startup, and could be too restrictive for sftdyn.

Support

For any new features, suggestions and bugs create an issue on GitHub. If you have any questions check and ask questions on community page Stack Overflow .

Find more information at: