freddo

joined 2 years ago
MODERATOR OF
[–] freddo@feddit.nu 3 points 3 months ago

No indication of it, other than them concluding the story now. On the other hand they resolved the bot crisis that was plaguing the game a while back, though no major updates other than the regular seasonal updates (such as Smissmas right now).

[–] freddo@feddit.nu 2 points 6 months ago

There is the passwd LDAP backend, not sure if it works for full auth though.

[–] freddo@feddit.nu 5 points 6 months ago

If you liked the old Rock Raiders game, check out Manic Miners. It is a free remake in a modern engine.

[–] freddo@feddit.nu 2 points 7 months ago (1 children)

I'm aware that this isn't how DNS works, but I'd imagine it is possible to have a DNS server that when it receives a query from the internet looks at the requested domain and translates it to an internal domain and in turn query that one, returning the result without revealing the internal domain. Something like a ALIAS virtual record provided by some services (but wont work against a internal DNS).

As for Traefik acting as a reverse proxy for internal network addresses, yeah that's the way it works. However in this case I have several instances of Traefik running on a subset of IP-addresses on a public subnet. So essentially we want to loadbalance several Traefik loadbalancers using DNS.

 

So I've got a Consul cluster running for service discovery on a set of servers, some of which have public IP addresses. On some of these nodes I want to run Traefik (dynamically registered), which are registered on tfk.service.consul which holds a number of A and AAAA records. I want my address tfk.example.com to point at those A-records without revealing the consul address.

How would I do this?

Example:

Some application maps internal A-records to public A-records.

public             | internal               / xxx.xxx.xxx.xxx
tfk.example.com -- | -- tfk.service.consul -- yyy.yyy.yyy.yyy
                   |                        \ zzz.zzz.zzz.zzz
Expected result:

Public DNS resolvers never see the consul query.

public           / xxx.xxx.xxx.xxx
tfk.example.com -- yyy.yyy.yyy.yyy
                 \ zzz.zzz.zzz.zzz

I know I could use consul-template for this purpose by rendering config files to bind or similar, but I was wondering if there was some way to do this via DNS like some kind of bridge application.

 
 

cross-posted from: https://feddit.nu/post/5631686

Jag tänker börja måla en svensk flaga från 280, 74 och ner till höger ifall någon vill hjälpa till.

 

Jag tänker börja måla en svensk flaga från 280, 74 och ner till höger ifall någon vill hjälpa till.

[–] freddo@feddit.nu 2 points 9 months ago

Som det ska vara

[–] freddo@feddit.nu 4 points 11 months ago (1 children)

Is it really a problem that they want to stay faithful to the original game? You say it yourself that FIRS is available as an option for people who want something more advanced to work with, along with all the other NewGRFs.

[–] freddo@feddit.nu 5 points 11 months ago (2 children)

Is it possible to just run your own SIP-trunk? We're not intending on sending or receiving calls from external numbers outside of our little network.

[–] freddo@feddit.nu 4 points 11 months ago (1 children)

What do you mean by "a block of external phone numbers?" We'd like to simply have our own internal numbers ideally, nothing to connect to the regular phone network.

[–] freddo@feddit.nu 2 points 2 years ago* (last edited 2 years ago)

Depending on the services you provide, the usual standard ports. So if you run http/https services, port 80 and 443 respectively.

You seem to answer your own question.

[–] freddo@feddit.nu 9 points 2 years ago

Minesweeper and various solitaires, which are decent enough to pass time.

[–] freddo@feddit.nu 2 points 2 years ago

I'd say the main benefit gained is sovereignty and a sense of place. This is not for personal use, but rather for a computer enthusiast association that I'm part of, so having our own git to integrate with the rest of our services makes sense. Throw on branding and link it to our SSO.

view more: next ›