On Mon, Apr 04, 2016 at 08:44:10AM +1200, Daniel Reurich wrote:
> Also Let-encrypt - this is a major frustration we can't afford to wait
> around for that and have broken websites for the duration. Just buy
> some certs and look at it in years time. Not being able access to
> files.devuan.org or browse packages.devuan.org for over a week is
> terrible. My clients would fire me if I let their sites do that for a
> day!!!


I agree with that.. BUT:

It *isn't* "letsencrypt", it's cause it's used in the wrong way.

There is a week limit. We should know and open certificates in the right
way ( one a week the first time, so, updates are one a week and we have
4 more in case of needs ).

Also, files.devuan.org, isn't hsts, it's a 443 closed: why no one open
it? i don't have access to the files machine, who fix it?


> I'm so tempted to quit devuan because it's just so hard to get the
> necessary stuff done (due to key people not being available and not
> making sure there are others that can step in if issues arise). I've
> spent hundreds of hours on Devuan and right now I'm so embarrased and
> ashamed at the state of our websites, and the state or our
> infrastructure that I'm considering whether to pull the plug on my
> involvement.

Of course I'm the one, and you are right. Except that the major issue
isn't cause of my assence, and on the more problematic machine ( files )
i don't even have access. The other one is "ci", that isn't exactly a
"public one". And the other is packages, ok, but the repository isn't to
be browsed by hands and in apt it works...

Anyway, ci is fixed now, and packages will be in few minutes. For files
i cannot do anything.

> 1) No Devuan server or service should have only one "key man". There
> must be a minimum of 2 active and easily contactable people with root
> access to any server. If you don't want to hand keys over due to
> concerns of exposing other non-devuan related systems, then it's time to
> move those Devuan services to a Devuan exclusive service or server.
> This goes especially for things like DNS and SSL cert accounts. (We
> should setup a team to deal with handling those anyway.)

There is no "ssl account", if you can accessthe machine, you can manage
ssl certs. For DNS, it's the only one that i insist it remains where it
is. To have access, we must write something over the ovh api.

For the rest, it's just matter to fucking find the time to fix some
routing things: for packages for example, i will be happy to give you
ssh access... but there is no ssh installed on the machine. I access in
console. I have to install ssh ( ok it's just an apt-get ) and modify
routing/firewalling to let you in. And explain how it's done, dak is a
piece of shit.

Anyway, during this week i will give you access to all machines,
promises.


--

Franco Lanza
My blog: http://www.nexlab.it
email: nextime@???
Fax/Tel: +39 0331 682151
Cell: +39 339 8125940
paypal: https://paypal.me/nexlab
Lonate Pozzolo (VA) - Italy
-----------------------------------
NO TCPA: http://www.no1984.org
you can download my public key at:
http://danex.nexlab.it/nextime.asc || Key Servers
Key ID = D6132D50
Key fingerprint = 66ED 5211 9D59 DA53 1DF7 4189 DFED F580 D613 2D50
-----------------------------------
echo 16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D212153574F444E49572045535520454D20454B414D204F54204847554F4E452059415020544F4E4E4143205345544147204C4C4942snlbxq | dc
-----------------------------------