headcounter / deployment Goto Github PK

https://developer.mozilla.org/en-US/Persona/Implementing_a_Persona_IdP

Currently, we have a few rooms which are logged. These logs are served via HTTPS and we have both private and public logs.

These logs come with two problems:

• They contain nick names so they might be a privacy concern.
• Difficult to migrate because of very complex web server rules.

I'm personally leaning towards not migrating them at all and let them die for good until we have a new logging mechanism which properly anonymizes the conversation (which is hard to do, because even the structure of the sentences can reveal user identity).

Have a look at https://github.com/otalk/restund, which might be usable.

We want to have things like conference.headcounter.org show up in the service discovery list for other virtual hosts as well.

The anonymous.headcounter.org vhost is currently disabled because I just found a massive amount of anonymous entries for mod_last and other tables.

We really want to make sure we have the proper access control rights set so that anonymous users won't pollute our database.

I'm not yet sure why they're unable to connect, but clients such as Adium or Gajim (the latter only on Windows) even in recent versions are unable to connect.

Gajim on Windows even tries to authenticate without doing STARTTLS first, but haven't yet been able to debug why this is happening (debugging Gajim on Windows seems to be quite annoying).

Currently we only have 1024bit DH params enabled, which is a "bit" weak, so while we also offer ECDHE key exchange and would like to drop DHE cipher suite we really can't do that at the moment, because some clients do not support ECDHE key exchange.

So, in short: Let's provide reasonable secure DH params.

And let's do it by patching them into OpenSSL directly so we can take advantage of that on every server component that's using OpenSSL... at least if that's possible to easily patch it in :-)

It might be a very good idea to note users who are trying to register for a particular transport, that the password has to be stored in clear on the server. We could encrypt the password based on the XMPP password, but that way the admin can still extract the cleartext password from RAM.

So in any case, let's warn the users properly.

Not all clients support XEP-0016 and it's also a very good idea to set/activate privacy lists before you actually spit out <presence/> information.

Right now, the Erlang cookie files are all over the place in the store, so let's use deployment.keys instead to ensure that the cookie isn't world-readable from the store.

This is useful for sending build failure notifications and for serving public malinglists in conjunction with Mailman.

Things left to do in no particular order:

• Rewrite the type for config so that whenever something like config.alias_maps.hash is specified, the corresponding map file is automatically created.
• Run each Postfix service as a different user.
• Provide a sane default configuration.
• Add module assertions for impossible service configuration combinations.
• Improve NixOS VM test.
• Handle processLimit.
• Set ambient capabilities for Postfix services.
• Move sockets to /run.
• Implement chroot and namespacing.
• Add a postfix.target to better control all Postfix service units at once.
• Implement waking up Postfix services.
• Strip down postmap to just map file creation.
• Properly set permissions on sockt files.
• Get rid of postdrop group.
• Add an option for Postfix service description.
• Implement custom merge function for the config option so that scalars is merged using lists.
• Take care of helper programs like sendmail or postqueue.
• Perform extra validation of the config file during build time.
• Log to stderr instead of syslog.
• Adjust throttling of service restarts.
• Implement high level abstractions (like eg. cfg.maps or cfg.restrictions).

https://headcounter.org/hydra/build/739447#tabs-summary

It is probably necessary to delete all Haskell-related store paths.

This virtual host is quite annoying as it needs quite a lot of stupid exceptions in the configuration and it will even get messier after the refactoring of the vhost modules.

There is only one user on that virtual host and he's inactive since 5 years.

We already use reltool for release handling, but everything still boils down to mongooseim.service. This has the downside that we need to restart the XMPP server on every single change, even though we don't have to if we would have an OTP service which just runs the Erlang VM. The latter needs to be restarted only whenever there is a new Erlang release and the mongooseim.service just reloads its code using the relup file.

The main goal of this repository is to allow people to contribute to the deployment, so let's make it not only easy to run the whole deployment on virtual machines but also describe more about the structure of the repository and how to get started.

Error is here:

command `nix-prefetch-git /var/lib/hydra/data/scm/git/e582c28417f6f404a7d873adf049f236684ca28345c096ca90587e6225602a18 f26ca1fd6437082883ec8614c675f3ee2927de60' failed with exit status 256 at /nix/store/aahvmfmki0hc5s5l86bgaya5814hrkg0-hydra-0.1/libexec/hydra/lib/Hydra/Helper/Nix.pm line 410.

These need to be signed by a >1024bit CA root, right now the chain leads up to a 1024bit root certificate which will trigger a certificate error on some systems.

The server is dismissed for September the 2nd, so let's fetch all crap from it and wipe it securely.

We need to have a bytestream proxy (XEP-0065) to ensure that SI/Jingle file transfers work properly behind NAT.

So either we have to implement it by ourselves or port it from ejabberd.

This should make it easier to do future announcements without annoying users with XMPP messages or using the GitHub wiki.

MongooseIM has support for MAM, so let's configure and activate it after we have our own specific tests for it.

It should only support Personal Eventing Protocol at the moment.

Currently, we have two available Web clients, one is jwchat and another one is Jeti. The latter seems to be unused and also nowadays really nobody really wants to run a Java applet in the browser, so we can drop it without replacement.

So, we only need to have a replacement for jwchat, either stay at it or move to an alternative like Jappix.