:: Re: [devuan-dev] internal list for …
Kezdőlap
Delete this message
Reply to this message
Szerző: Daniel Reurich
Dátum:  
Címzett: devuan developers internal list
Tárgy: Re: [devuan-dev] internal list for developers
On 04/04/16 16:39, Franco Lanza wrote:
> 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.


Then we need a procedure and instructions for managing it properly.
>
> 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?


It is a hsts issue because HSTS has been setup on www.devuan.org and it
has told any browser that visits that site that any subdomain of
devuan.org must use https.

If I visit http://files.devuan.org in private browsing mode then it
works fine.. same for packages.devuan.org
>
>
>> 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.


Actually you are not specifically the cause of my feelings... it's more
a point we've got to which feels like we've hit the barriers of what is
sustainable with our current manpower. Please don't take my comment
personally as it was not directed at you!!!

I understand your busy but also the reluctance to grant root access to
the servers, but we need ways to continue to action things when you are
unavailable.


> 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...


I often do browse by hand just to see what is actually in the Packages
files.
>
> Anyway, ci is fixed now, and packages will be in few minutes. For
> files I cannot do anything.


CI cert was outdated, but that could be worked around in browser ;-)
Having packages with https is good though. Thanks for sorting that.
>
>> 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.


With regards to SSL's the auth process is tied to the admin or technical
contact email address, so that is still centralised to a degree.
>
> 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.


Then we continue to work to get rid of Dak ;-) I've found the
documentation of it in Debian so I should be able to work that piece of
shit out. ;-) (BTW Dak is slang here in NZ for marijuana - perhaps
that's what one needs to smoke before being able to cope with it :-D )
>
> Anyway, during this week i will give you access to all machines,
> promises.
>




Franco: I do very much appreciate the work you do for Devuan, and have a
great deal of respect for your work. You're far ahead of me in many
areas - programming particularly, but I do have a little more time so
handing over what you can so you can focus on the magic bits will help
us both ;-)

Regards,
    Daniel.
-- 
Daniel Reurich
Centurion Computer Technology (2005) Ltd.
021 797 722