:: Re: [devuan-dev] internal list for …
Kezdőlap
Delete this message
Reply to this message
Szerző: Alberto Zuin - Personal
Dátum:  
Címzett: devuan developers internal list
Tárgy: Re: [devuan-dev] internal list for developers
Hi all,
I'm not a real developer here but just my two cents:
- - I had another talk about devuan last Friday and I had the same positive impressions of the first made with Jaromil: the only one issue regards the release time which takes ages and now it's time to proceed with beta as soon as possible or we loose time to market.
- - all the infrastructure hosted on my servers (gitlab and 2 build servers) is accessible from outside by more than one sysadmin: me and Franco have root access and I'm pretty sure that someone else has it, at least for gitlab server. Also both me and Franco have access to the VMs via vnc in case of major issues.
- - about DNS: I don't host the professional service on my infrastructure anymore because the business chose to release the system in an opensource way and focus on maintenance contract: I can ask to one of our customers to host devuan zone or, if you prefer, we can use Amazon route 53 via the account used for gitlab backups. Last, I have enough space in my infrastructure to host a pair of VM with bind or powerdns, but in this moment I really think is better to focus on beta release and avoid loosing time with less important tasks.
- - about the SSL: I'm using letsencrypt and I'm really happy with it, but if we have particular needs, let's switch to something else. At the end are some quids per year, it's not a big problem.
- - last: in this moment gitlab server is becoming the centre of our infrastructure: even if we have nightly backup on Amazon glacier, I think is better to start thinking about a replicated environment on another datacenter.

Cheers,
Alberto


On 3 April 2016 22:07:44 BST, Jaromil <jaromil@???> wrote:
>On Mon, 04 Apr 2016, 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 absolutely second this observation. This is ridicolous and we cannot
>go further waiting for lets-encrypt. I'm surprised we did so far. I'm
>rather depressed and frustrated by it. Its ruining every single new
>day and I'll take over the task if there is no immediate solution
>tomorrow.
>
>> 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.
>
>Daniel please do not quit. there is a serious horizon of success, lets
>push it to the beta and then draw conclusions. I'm determined to
>support this and if necessary to form a new team. I also know that
>Franco has little time but will stick around for sure.
>
>> Here is a start on our core infrastructure principles which are
>needed
>> in order to sort out the "key man" problems we are having.
>
>> 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.)
>
>agree.
>
>I can setup the DNS handling on a git repository of zone text entries.
>
>Also Alberto has a professional service to handle DNS and open it to
>more people, he has offered to me this service already.
>
>> 2) All Devuan code should be in gitlab - including in development
>code
>> before deployment. This allows for better design and discussion and
>> also reduces the likelyhood of "key man" issues and replication of
>> efforts to solve the same problem.
>
>agree.
>
>> I'm sorry this is a bit of a rant, but we're close to beta and keep
>> hitting and being held up by very basic issues that should make any
>> VUA ashamed to be associated.
>
>I think on your side it feels and looks worst than it is. I keep in
>touch with Franco who is very responsive on urgent issues, but mostly
>in Italian language since that is quicker. But you are right on all
>points above and I believe we all rely and love this project enough to
>make an effort and let go to put it in the middle and and the hands of
>others.
>
>
>but now, enough with the long term, we need a short term solution to
>the SSL problem. I'm asking hellekin about this since he has been
>closer following the issue, but will have to take it up myself if its
>not solved tomorrow, making a certificate and changing the
>configuration.
>
>
>Franco: please do reply to this and enable us on DNS and all hosts,
>else we'll also have to switch the domain to something else. Loosing
>developers and their agency right now is the worst thing that can
>happen. I have done my best to activate everyone towards beta but what
>is happening in fact is the worst slow down and boycotting as
>possible, I'm sure not intended, but that's the outcome of lack of
>action.
>
>ciao
>
>_______________________________________________
>devuan-dev internal mailing list
>devuan-dev@???
>https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/devuan-dev


- --
Sent from my Android device with K-9 Mail. Please excuse my brevity.