2009/2/19 Michael DeHaan <[email protected]>
> ... snip ...
> >
> > Let's sum up my thoughts in less words.
> >
> > When you add a repository with --mirror-locally=0 (or 'N' or 'False'),
> > cobbler suppose the repository is remote and it references its path
> > (or URL). When the repository is available to cobbler through a
> > locally mounted nfs share, it references only the path, forcing all
> > servers needing access to this repository to mount this nfs share in
> > this exactly same path (in %pre section of kickstart). When the
> > repository is fully local to cobbler server, it's even not an issue...
>
> We do not support repositories on locally mounted NFS shares. Neither
> does yum, IIRC. They must be http/ftp.
>
I probably made a confusion with import option, and my personal wishes... ;)
> >
> > Thus, I think that an option
> > --path={local|nfs}:[nfs_server:]<path_to_repo> could be used for those
> > cases, implying --mirror-locally=0. A link in
> > /var/www/cobbler/repo_mirror could be automatically created to make
> > cobbler a provider for those repos through httpd. The repo stanza in
> > kickstart would then be quiet simple, adding a repo entry...
>
> I would prefer in these cases folks just take the neccessary steps to
> surface those yum repos that they do not wish to mirror externally.
>
> I will not be adding this feature since not many people would use it,
> and it's not hard to do for people that do care. The existing
> --available-as on import is too confusing already.
I know it's quite easy through a simple webserver. Not always that obvious
due to company's policy.
But I understand your position...
> >
> > A concrete use case would be a central storage for repositories
> > (mirrors and local) on a NFS appliance, accessed by multiple cobbler
> > servers, depending on the computers environment (development,
> > integration, test, production, workstations...). The NFS share(s)
> > would be 'proxified' through cobbler's httpd server, enforced by
> > Apache security limits (https, acls, we could even imagine client
> > certificates distributed in %pre stage).
>
> It would be easier to just set up a Apache server on that "central
> storage for repositories server" and set up Apache rules there, in that
> case. Even if not, you could easily set up the mount points and make
> this all web accessible yourself.
>
> (And is NFS ever really secure?)
>
> Regardless, you have options to set this up as you see fit today, and
> because it's a special use case, it need not be something that cobbler
> automates.
>
> We walk a fine line between things that we do automate and make simple,
> and exposing more complex options that require a lot of user support and
> Q&A when they are trying to figure them out. Keeping the number of
> options like that small is something I am generally interested in doing,
> to keep the tool easy to use. In the more advanced cases, people will
> know how to set up those workflows.
>
> I am interested in providing a toolbox, not neccessarily a workflow.
Thus, I may look forward Spacewalk for the workflow implementation through
channels.
But I'm not sure it's as easy as cobbler to understand and manipulate with
simple files (/var/lib/cobbler/config is really clear). And as far as it
doesn't support PostgreSQL, I won't be able to have it working... but time
is on my side.
I'll maybe take a further look to cobbler's API (and learn python) to try
and develop a local workflow through a quite user-friendly interface.
> --Michael
>
>
> _______________________________________________
> cobbler mailing list
> [email protected]
> https://fedorahosted.org/mailman/listinfo/cobbler
>
_______________________________________________
cobbler mailing list
[email protected]
https://fedorahosted.org/mailman/listinfo/cobbler
