ace

joined 1 year ago
[–] [email protected] 1 points 10 months ago (2 children)

You could also just run IMAP/JMAP/SMTP as separate components, I can't see any place in the Stalwart documentation - or in the Docker image itself - where monolith is the only option.

I haven't tested the setup myself yet, but me and another root are planning on testing a setup of Stalwart to replace a semi-broken IMAP/JMAP setup for a computer club, keeping the SMTP as is.

[–] [email protected] 1 points 11 months ago

Probably not what you're looking for, but I'm going to note that Turris make some great OpenWRT routers.
Currently running theTurris Omnia, and using both Wireguard and Yggdrasil through it.

[–] [email protected] 9 points 11 months ago (3 children)

I've been personally using KDEs Itinerary app, but it might not be what you're looking for

[–] [email protected] 3 points 11 months ago (1 children)

We've recently kicked out our entire Cisco networking core due to it actively refusing to interoperate with other pieces of necessary hardware for us, which was causing us to have to run an almost entire second redundant core network. Switching it out with ALE has been really nice in that regard, SPB scales like a dream even between locations and cities, we even get working L2 routes all the way over to some of our locations almost half a country away.

For us, Dell has been the far better of the two (HPE/Dell) big server-providing beasts in terms of just being able to use the hardware they provide, but they're very close to getting a complete block from future procurement due to how they've been treating us.

Honestly, Fujitsu is probably our best current provider; their hardware is reasonably solid, their rack-kits aren't insane, their BMC doesn't do a bunch of stupid things, they don't do arbitrary vendor locking on expansion cards, etc. Unfortunately their EFI/BIOS is a complete mess, especially in regards to boot ordering and network boot, and they've so far not been able to provide us Linux-based firmware upgrade packages - despite using a RHEL image in their BMC-orchestrated offline firmware upgrade process.

[–] [email protected] 6 points 11 months ago (3 children)

Got a pair of old HPE gen8 1U servers that are chewing through fan packages like nobody's business, replaced at least five burnt-out fans on them in a similar amount of years.

We're running a mix of HPE, Dell, and Fujitsu servers and they all absolutely suck in their individual ways - HP(E) adds a bunch of arbitrary hardware limitations which we have to work around, Dell intentionally degrades our multi-system setups with firmware updates, and Fujitsu's boot firmware goes absolutely pants-on-head retarded if you're doing netboot first.

We've gotten some Supermicro systems now as well, and they've been a real treat in comparison, though their software UX feels like it's about two decades behind.

[–] [email protected] 4 points 11 months ago (1 children)

It's great to hear that they're not just giving up. And it's also definitely good to hear that they're not sticking with PHP either, that language is a true bane to modern hosting - and especially Kubernetes.

I'll remain cautiously optimistic that they'll be able to stay relevant, and not go hard in again on cutting away core functionality in the name of enterprise offerings - what caused the NextCloud split in the first place.

[–] [email protected] 28 points 11 months ago (3 children)

Has anything actually happened in ownClouds development?

The last I saw of them was FOSDEM a few years back, where NextCloud were handing out whitepapers and showing off their new Hub, chat, VoIP stack, group sharing system, and more. And ownCloud were sat somewhat opposite with two people and a screen showing a screenshot of a default ownCloud install, along with a big sign hanging from the ceiling saying "Join the winning team."

[–] [email protected] 6 points 1 year ago (6 children)

Lots of people instantly think of security when they look at WiFi-connected IoT devices, but oftentimes they never think of the WiFi signal itself - what with all the added communication noise and send time limitations of having lots of small devices.
Especially with regular consumer equipment, it doesn't actually require that many devices to fully saturate a regular home router or AP.

[–] [email protected] 1 points 1 year ago

I think the file upload size limit could become a problem in my case, at least in terms of posting the complete ACLs.

We've recently managed to come down to only ~1.4k VLANs though, and the network firewall pair for our server networks now only handles ~600 SPB services.

[–] [email protected] 1 points 1 year ago

A possibly metal battleaxe.

[–] [email protected] 3 points 1 year ago (1 children)

I've spent literally the entire last month working on tooling to orchestrate our asset management database for NAC (Network Access Control) purposes, and somehow I still didn't think of this.

[–] [email protected] 4 points 1 year ago

If you're taking part in transmitting a torrent over Yggdrasil, then people you've peered with in the swarm will definitely see your Yggdrasil IP - which is based off of the encryption key you generate (and you can change whenever you wish) for the connection to the mesh.
Regarding obfuscation of what you're accessing inside something like the bittorrent DHT, that could likely be done with multiple Yggdrasil connections and torrent clients - so each address only associates with one torrent, it's just not a core feature of the network itself.

The Yggdrasil network really isn't meant to provide perfect internal anonymity between two directly communicating peers, it's instead built to be an easy-to-use, end-to-end encrypted, mesh network - with great performance.
It's there to protect the content and target of your communications from anyone beside you and said target, without adversely affecting the delivery of said content. Not to protect you from your communication target, though it can do a passable job at that too.

My main use of Yggdrasil has actually been as an easily setup alternative route into NATed systems, seeing as I can easily hit 600Mbit and get below 15ms of latency over it, which I quite often use to run VNC or SSH (and SCP/rsync) over. And since the mesh can be established as long as you can reach a node, it becomes ridiculously easy to get a functional link over it.
Transmitting DC++ traffic without my ISP being able to detect any of that is just a bonus.

view more: ‹ prev next ›