[mirror-admin] push mirroring plans

[Simon Valiquette]

 >>>>
 >>>> In our network policy, SSH access from outside of our network
 >>>> is prohibitted. I can not change this because this policy is the
 >>>> decision of our company. So, our server may be stopped the mirror if
 >>>> only "push mirror" is provided for official mirror.
 >>>>
 >>>> I think that debian provides both pull and push miror. If possible, I
 >>>> would like to use "pull mirror" continuously.
 >>>>
 >>   Exact, and I see no reasons why RedHat would want to prevent mirrors
 >> from polling from the master.  Actually, it would even involve
 >> unnecessary efforts to enforce it.
 >
 > I think Matt is telling about a new feature of pushing data, not about
 > removing some features. I think standard pulling will be not changed.

   I had no objections with what Matt proposed. I just answered a 
question, and explained at the same time why RedHat probably have no 
intention, and no reasons, to stop mirrors from pooling from them.

>>   Much better, much simpler and quite safe is to trigger the sync with an 
>> email, like what kernel.org do. Configuring Postfix or something else to  
>> trigger the sync when receiving the email is quite simple, and have far  
>> better chance to comply with Shinbo-san company policy.
> 
> Heh, 3rd solution. :-)
> 
> I still prefer more push over ssh. What's are advantages:

   I also prefer that, and it is also what I do with my mirror (I manage 
one of the Debian master mirror for Canada). But I didn't had any problem 
to get the permission to open the SSH port.

>   - I can set IP access filter for ssh on my server to only for RH IPs

   That is quite useless for Shinbo-san if his company refuse to open the 
firewall to allow incoming SSH connections to his mirror.

>   - I can set for a tier mirror's ssh key to run only specified command
>     (for example a special rsync, where this server can't do more like
>     sync content)

   For a mirror, that is the normal way to configure it.  Maybe Shinbo-san 
will be able to convince his company to allows SSH on an alternate port, 
but I already worked in Japan and I know that it can be quite difficult. 
It is so because the person that will allow him to open the port will also 
have to take the responsibility if there is a problem later.

>   - it's secure
>   - it's simple (just one command)

   Depending of their security requirement and risk tolerance, it might be 
a reasonable policy to not wanting to trust potential misconfiguration or 
bugs in OpenSSH if it is not absolutely needed.


> Using email this need to be done:
>   - procmail or something similar is required, need to define proper
>     access right, adapt selinux policy to allow running rsync on ftp
>     content from procmail
>   - I need to open port 25 (smtp) for whole world, or at least for our
>     SMTP gateway

   Not true.  You can configure fetchmail to get the mail directly from 
the mail server and then use procmail as usual.  It is probably the 
solution I would use, and there is good chance that his company would accept.

   It would also be possible to configure the company mail server to 
internally route the mail to the mirror, which will accept mail only from 
this host. From there, it is quite easy to configure postfix to pass the 
email to  a script that will trigger the syncing without needing to use 
procmail at all if you wish so.

   This second solution is probably too intrusive because changes are 
required on the mail server and possibly routing, but it is technically 
possible.  That said, the first solution is reasonnably simple and

>   - make a script, which can do some GPG magic to test, if it's email
>     is not a fake

   If required, it is very easy to do that from procmail. Or why not go 
back to simply using UUCP? ;)

 > OK, it's 4th solution.
 >
 > There you need a cron job which run aprox. every 5 mins, which is not
 > a best idea too.

   Err, I think I won't bother comment on that one.

Simon Valiquette


--