Fluree Server wraps the fluree/db library with an HTTP API server and consensus capabilities. While fluree/db can be used directly in applications for embedded database functionality, Fluree Server provides the infrastructure needed for multi-client environments requiring consistent transaction ordering, ledger state management, and distributed consensus.

The server can run as either a consensus-participating node for transaction processing or as a query-only node for horizontal scaling. Multiple servers can form a cluster for fault tolerance and performance.

Key Features:

• High Availability: Automatic failover and work redistribution when servers join or leave
• Guaranteed Ordering: Consistent transaction processing across all nodes
• Horizontal Scaling: Add query-only nodes for read performance
• Load Distribution: Automatic workload balancing across consensus nodes
• Duplicate Prevention: Built-in transaction deduplication

Technitium DNS Server is an open source authoritative as well as recursive DNS server that can be used for self hosting a DNS server for privacy & security. It works out-of-the-box with no or minimal configuration and provides a user friendly web console accessible using any modern web browser.

Nobody really bothers about domain name resolution since it works automatically behind the scenes and is complex to understand. Most computer software use the operating system's DNS resolver that usually query the configured ISP's DNS server using UDP protocol. This way works well for most people but, your ISP can see and control what website you can visit even when the website employ HTTPS security. Not only that, some ISPs can redirect, block or inject content into websites you visit even when you use a different DNS provider like Google DNS or Cloudflare DNS. Having Technitium DNS Server configured to use DNS-over-TLS, DNS-over-HTTPS, or DNS-over-QUIC encrypted DNS protocols with forwarders, these privacy & security issues can be mitigated very effectively.

Be it a home network or an organization's network, having a locally running DNS server gives you more insights into your network and helps to understand it better using the DNS logs and stats. It improves overall performance since most queries are served from the DNS cache making web sites load faster by not having to wait for frequent DNS resolutions. It also gives you an additional control over your network allowing you to block domain names network wide and also allows you to route your DNS traffic securely using encrypted DNS protocols.

Welcome to the VPN server documentation page. This site is intended for VPN server operators. It contains information on how to deploy the VPN software on a server, but also (technical) details on how to (better) integrate the software in existing infrastructure, and how configure the software for one’s own organization.

This is an (incomplete) list of features of the VPN software:

• OpenVPN server accepting connections on both UDP and TCP ports;
• Uses multiple OpenVPN processes for load sharing purposes;
• High Available deployments with multiple portals and nodes;
• Scales from a Raspberry Pi to many core systems with 10GBit networking;
• Full IPv6 support, using IPv6 inside the tunnel and connecting over IPv6;
• Support both NAT and Public IPs;
• Embedded CA for managing OpenVPN client certificates;
• Full support for WireGuard;
• Secure server and client configuration out of the box;
• User Portal to allow users to manage their VPN configurations on their devices and Admin Portal to manage users and connections;
• Internationalization / Localization support;
• Authentication to portals using Local User DB (default), LDAP, RADIUS, OIDC, SAML and Client Certificates;
• OAuth 2.0 API for integration with native eduVPN/Let’s Connect! applications;
• Deployment scenarios:
  • Full Tunnel to route all traffic over the VPN (for safer Internet usage on untrusted networks);
  • Split Tunnel to route only some traffic over the VPN (for access to the organization network);
  • Client-to-client (only) networking;
• Group Permissions support with SAML, LDAP authentication backends as well as “Static”;
• Ability to configure Logging;
• Support multiple deployment scenarios simultaneously;
• SELinux fully enabled (on Fedora, EL);
• Usage Statistics and Monitoring;
• Some Preview Features;

Alternative implementation of the Bitwarden server API written in Rust and compatible with upstream Bitwarden clients*, perfect for self-hosted deployment where running the official resource-heavy service might not be ideal.

Basically full implementation of Bitwarden API is provided including:

• Organizations support
• Attachments and Send
• Vault API support
• Serving the static files for Vault interface
• Website icons API
• Authenticator and U2F support
• YubiKey and Duo support
• Emergency Access

Gitea lacks the ability to host static pages from Git. The Codeberg Pages Server addresses this lack by implementing a standalone service that connects to Gitea via API. It is suitable to be deployed by other Gitea instances, too, to offer static pages hosting to their users.

End user documentation can mainly be found at the Wiki and the Codeberg Documentation.

WireGuard is a fast and modern VPN protocol.

It is a point-to-point VPN, which means it does not have a client-server architecture, but peers, and does not rely on a PKI, unlike OpenVPN. It is super simple to setup to connect multiple machines together.

WireGuard supports roaming, which means you can switch between network connections and not have to reconnect to your peers. On servers, it’s rarely useful, but when one of the peer is a mobile client like a laptop or a smartphone, it’s a life saver, because the usage of WireGuard is completely transparent.

I’m used to OpenVPN, I even maintain a quite popular script, but WireGuard is better in pretty much all aspects.

The holy cow of servers.
Ranch is a socket acceptor pool for building awesome TCP and TLS servers

Small, fast, modern HTTP server.
Cowboy is the ultimate server for the modern Web with support for Websocket, HTTP/2 and REST.

This model features a unique modular interior for outstanding configurability

Compact, modular interior
Minimalistic design with an elegant aluminum front panel
Unique new modular mounting system that accommodates up to six hard drives

Async Language Server Protocol plugin for vim8 and neovim.

ALE makes use of NeoVim and Vim 8 job control functions and timers to run linters on the contents of text buffers and return errors as text is changed in Vim. This allows for displaying warnings and errors in files being edited in Vim before files have been saved back to a filesystem.

In other words, this plugin allows you to lint while you type.

ALE offers support for fixing code with command line tools in a non-blocking manner with the :ALEFix feature, supporting tools in many languages, like prettier, eslint, autopep8, and more.

ALE acts as a "language client" to support a variety of Language Server Protocol features, including:

• Diagnostics (via Language Server Protocol linters)
• Go To Definition (:ALEGoToDefinition)
• Completion (Built in completion support, or with Deoplete)
• Finding references (:ALEFindReferences)
• Hover information (:ALEHover)
• Symbol search (:ALESymbolSearch)

If you don't care about Language Server Protocol, ALE won't load any of the code for working with it unless needed. One of ALE's general missions is that you won't pay for the features that you don't use.

Help Wanted: If you would like to help maintain this plugin by managing the many issues and pull requests that are submitted, please send the author an email at dev@w0rp.com.

If you enjoy this plugin, feel free to contribute or check out the author's other content at w0rp.com.

Pyright is a fast type checker meant for large Python source bases. It can run in a “watch” mode and performs fast incremental updates when files are modified.

Kea is open source, shared under MPL2.0 licensing. Kea is developed in the open on ISC’s GitLab; we welcome you to open issues and submit patches there. Kea runs on most Linux and Unix platforms, as well as MacOS. If you don’t want to build from our source distribution, we also provide a repository of pre-built packages for most popular operating systems.

ISC distributes and maintains TWO open source, standards-based DHCP server distributions: Kea DHCP and ISC DHCP. Kea includes all the most-requested features, is far newer, and is designed for a more modern network environment.

How is the Kea DHCP server different from the older ISC DHCP?

1. Modular Component Design, Extensible with Hooks Modules. The Kea distribution includes separate daemons for a DHCPv4 server, a DHCPv6 server, and a dynamic DNS (DDNS) module. Many optional features are enabled with dynamically-loaded “Hooks Modules,” which you need run only if you are using them. You can write your own hooks modules (in C++) or try some of the hooks we offer.

2. On-line Re-configuration with REST API Kea uses a JSON configuration file that can be modified remotely via set commands and reloaded without stopping and restarting the server, an operation that could take quite a while with ISC DHCP.

3. Designed to Integrate with Your Existing Systems. Kea allows you to separate the data from the execution environment, enabling new deployment options. Your network data - leases, host reservation definitions, and most configuration data - can be located separately from the DHCP server itself, using a Kea “backend.”

4. Web-based graphical dashboard Kea now has a graphical dashboard for monitoring multiple Kea servers. This system, called Stork, uses agents deployed on the Kea servers to relay information to a centralized management platform, providing the administrator with an easy-to-use quick view of system status and activity.

Kea supports two database backends; MySQL and PostgreSQL. Choose to store leases, host reservations, or shared configuration data in a separate database backend. Benefits of this include:

• Integrate it more easily with your other systems - provisioning systems, IPAMS and so on - by storing critical data in a separate database.

• Use the same hosts reservations backend for multiple DHCP servers.

• Administer global options from a centralized configuration backend.

• Manage large address pools in a database rather than a text file.

• ISC gitlab Repository: Kea DHCP Server

• Kea DHCP Server Docs

The Gluu Server is a container distribution of free open source software (FOSS) for identity and access management (IAM). SaaS, custom, open source and commercial web and mobile applications can leverage a Gluu Server for user authentication, identity information, and policy decisions.

Common use cases include:

• Single sign-on (SSO)
• Mobile authentication
• API access management
• Two-factor authentication (2FA)
• Customer identity and access management (CIAM)
• Identity federation

Open Web Standards

The Gluu Server can be deployed to support the following open standards for authentication, authorization, federated identity, and identity management:

• OAuth 2.0
• OpenID Connect
• User Managed Access 2.0 (UMA)
• SAML 2.0
• System for Cross-domain Identity Management (SCIM)
• FIDO Universal 2nd Factor (U2F)
• FIDO 2.0 / WebAuthn
• Lightweight Directory Access Protocol (LDAP)
• Remote Authentication Dial-In User Service (RADIUS)

A Language Server for the latest version(s) of Jedi. If using Neovim/Vim, we recommend using with coc-jedi. Supports Python versions 3.6.1 and newer.

Note: this tool is actively used by its primary author. He's happy to review pull requests / respond to issues you may discover.

coc.nvim wrapper for Python's jedi-language-server.

If you would like to know more about why coc-jedi is useful, please read this blog post.

Requires Python version>=3.6.1.

Remotely was created by Translucency Software with the goal of making IT support tools that adhere to the following ideals:

• IT shops should be able to decide if they want to host their own servers.
• A remote console can be used to solve many problems without ever needing to inconvenience the user with full desktop control.
• Remote support tools should allow technicians to accomplish tasks without an excessive amount of clicking and waiting for pages to load.

This Ansible playbook is meant to help you run your own Matrix homeserver, along with the various services related to that.

That is, it lets you join the Matrix network using your own @<username>:<your-domain> identifier, all hosted on your own server (see prerequisites).

We run all services in Docker containers (see the container images we use), which lets us have a predictable and up-to-date setup, across multiple supported distros (see prerequisites) and architectures (x86/amd64 being recommended).

Installation (upgrades) and some maintenance tasks are automated using Ansible (see our Ansible guide).

In 2010, it was an easy decision to use a commercial DNSSEC signer to deploy DNSSEC on APNIC’s reverse zones. Because much of the signer’s management was automated, we only had to worry about updating the parent delegation signer (DS) record separately.

So, even though we had to consider the scheduled Key Signing Key (KSK) rollover, updating the parent DS record on time was never an issue, since it would not roll-off the old key unless the new DS record had been updated in the parent zone.

In 2019, RFC 8624 (Algorithm Implementation Requirements and Usage Guidance for DNSSEC) was released. The minimum recommended DNSKEY algorithm changed to RSASHA256, and there was a strong recommendation to use ECDSAP256SHA256 as it provides more cryptographic strength with a shorter signature length than either RSASHA256 or RSASHA512.

RSASHA1 was APNIC’s DNSKEY algorithm for almost 10 years, so the need to upgrade was it was inevitable. When it was time to upgrade, algorithm rollover was supported and well documented.

Following the recommendations in RFC 8624, we decided to migrate APNIC’s existing DNSKEY algorithm from RSASHA1 to ECDSAP256SHA256. The whole process took about a week to complete, without breaking the DNSSEC chain of trust.

Once we’d migrated, it was great to see the new (short) signatures from our zones.

What else could we ask for?

This document describes a method for automatic DNS zone provisioning among DNS primary and secondary nameservers by storing and transferring the catalog of zones to be provisioned as one or more regular DNS zones.