:: Re: [devuan-dev] (no subject)
Αρχική Σελίδα
Delete this message
Reply to this message
Συντάκτης: Ivan J.
Ημερομηνία:  
Προς: devuan developers internal list
Αντικείμενο: Re: [devuan-dev] (no subject)
On Tue, 11 Jul 2017, Daniel Reurich wrote:

> On 11/07/17 19:50, Ivan J. wrote:
> > On Tue, 11 Jul 2017, Daniel Reurich wrote:
> >
> >> On 11/07/17 19:36, KatolaZ wrote:
> >>> On Tue, Jul 11, 2017 at 07:26:54PM +1200, Daniel Reurich wrote:
> >>>> Hi Jaromil,
> >>>>
> >>>> I offered to do rsync push from amprolla but had no response. I think
> >>>> that we should avoid rsync pulls from the main mirror. If he must pull
> >>>> then we must setup an intermediary to pull from.
> >>>>
> >>>> Besides there is also a need to provide proper information about setting
> >>>> up the mirror properly with all the necessary redirects.
> >>>
> >>> grok has offered his help in testing the rewrites for apache. This is
> >>> a good opportunity to let people participate and help. Once set up the
> >>> first time, the same conf can be repeated endlessly...
> >>>
> >>> I think we must help people help us. We can't manage and control
> >>> everything. Devuan is growing up, and we need to do follow :)
> >>
> >> Sure, no problems, but the risks of pushing rsync are far lower for us
> >> then pulling rsync. In fact I think we should move the primary mirror
> >> to another host thus separating it from the amprolla process which would
> >> be a big security improvement.
> >>
> >> KatolaZ, shall we spin a vm on nemesis for this... oh wait ... jaromil
> >> relinquished our 16 IP addresses...
> >
> > Why can't you do NAT or some iptables magic for this "testing" process.
>
> It should be a public webserver, and that requires setting up routing
> etc. That becomes painful to setup and administer in the long term


I didn't think it was longterm. It would only be a requirement for the
time being, until we get the other IP addresses. Then the routing could
be reverted back with ease.

> > Also, what is the "big security improvement" coming with separation of
> > the amprolla process from the primary mirror? I would like to know.
>
> Protection of the signing keys - the amprolla server can be kept secure
> behind a firewall and just rsync push the repo's.


This seems okay. I reckon it would also allow the machine running
amprolla to use less disk space as the repository (/merged) would not
have to be generated in a 3-directory rotation scheme, but it could
rather be done on the mirrors. Does rsync pushing allow for command
execution remotely?

> >>>> Happy to work on this with you, but please stop with these unilateral
> >>>> actions. It's not a nice approach and is likely to just create problems
> >>>> and fray tensions.
> >>>>
> >>>
> >>> There is no need to fray tensions, but there is a pushing need to keep
> >>> things moving guys...
> >>>
> >> Sure, but discussion rather then unilateral actions, especially when
> >> those actions are taken by people that aren't deeply involved in those
> >> parts of the project and thus risk breaking things.
> >
> > Instead of you being the only one and not taking the time to help/teach?
> >
> I have been as best as I can, but my time is limited and the time zone
> thing is such a pain... and it's not like your always around. Lets set
> some times to get this done.


I am around, quite possibly more than most of the others are. I've tried
plenty of times to try and get things moving, and being ignored a lot of
times is to say the least - dissapointing. This thread was also one of
these tries.

Everything that needs to be done with the infrastructure is a two-night
hack at most. I fail to see why there was no time to do it over the
course of the past few months. I'm pretty sure everyone can find a free
night or two in a month. If not, maybe it should be reconsidered if the
unavailable person should be responsible for such an amount of work.

--
~ parazyd
GnuPG: 03337671FDE75BB6A85EC91FB876CB44FA1B0274
GnuPG: https://parazyd.cf/FA1B0274.asc