Stories
Slash Boxes
Comments

SoylentNews is people

The Fine print: The following are owned by whoever posted them. We are not responsible for them in any way.

Journal by janrinok

NCommander is publishing a Meta story today: https://soylentnews.org/article.pl?sid=22/11/20/0342250 It will be published on the front page with all of the restrictions that apply to such stories and discussions.

In it NCommander explains how he sees the future of the site developing with regards to software, hardware and administration. Some of those views are different now from the views that many of us held in 2014. The requirement for some of our servers is no longer justified, and there are better technologies available for achieving what we are trying to do thus also reducing our running costs. The administration of the site is placing an increasing burden on the relatively few administrators that remain in the support team. Society has also changed. Some discussion has been replaced by intimidation and threats. It is much more polarised than it was in 2014. In many ways this is the same as for numerous other web sites. However, the abuse and toxic atmosphere created by a small number of Anonymous Cowards is unacceptable and must be reversed if the site is to survive. The responsibility for some of the problems that we are experiencing, and the resulting actions that we have had to take, is placed entirely at their feet.

A few months ago the majority of the community opted - albeit very reluctantly - to remove AC posts from the front pages of the site. This action has successfully removed the vast majority of the abuse from our discussions. We are seeing a slow increase in the number of comments week-on-week and the signal-to-noise ratio is now much higher. It is only right that we also reconsider the implications of that change.

This journal entry is to enable anyone who wishes to remain anonymous to express their views. I promise that I will read it and will ensure that genuine views are considered when the community decides which path it wishes to follow. I cannot make any assurances that other members of the site's administration will read it - although I expect that at least some will. If you have an account then I strongly encourage you to leave your views under NCommander's Meta story and not here.

I further my promise that I will try to represent your views as honestly and fairly as I can.

If you abuse this journal then you are simply giving more support to the alternative options that might be considered than you are to the status quo. I encourage you to expresses sensible, logical and considered views but should you decide that abuse is what you prefer then this journal entry can simply be removed. You are being given an opportunity - do not throw it away.

Display Options Threshold/Breakthrough Reply to Comment Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 0) by Anonymous Coward on Tuesday November 22 2022, @12:17AM

    by Anonymous Coward on Tuesday November 22 2022, @12:17AM (#1280927)

    It is possible for this site to fully automate their usage of LE, which is what the TSIG is for. Because SN is using BIND, you can use TSIG to alter the _acme-challenge DNS entries in a secure manner without affecting anything else in the zone.

    As a bonus, it also allows you to create the TLSA entries for the new certs and delete the old ones, again in a secure manner without affecting anything else on the zone. Your deployment script can handle all of that for you, and there are a couple of examples out there (I think ARIN or USCERT have one) and I know people who do so at scale already using such a script. The basic process is to start certbot. It can use its TSIG mode to create the proper challenge entries and get the wildcard certificate. Your deployment script generates the hash for whatever TLSA entry you chose. You use TSIG to add the new TLSA record. You wait 2.5 times your DNS value (which would be 2.5 hours according to the current SOA but you could do 2 days for safety). Then you add the new certificates and keys to nginx and remove the old ones. Then you reload nginx, being sure to wait for the reloads to actually complete. Then you can safely delete the old TLSA record using TSIG because you can be assured no one is relying on it.