[et-mgmt-tools] Re: Cobbler import --path weirdness

[Michael DeHaan]

Aaron Lippold wrote:
> Will do. Thanks for the help. So not using import but distro and
> profile may eliminate this issue?
>
Yes...
> Question, one of the issues when using a mass storage device, like NFS
> mounted NAS, is that we usually mount these things squash_root for
> security and since we run cobbler as root, it can't write to the
> destination.
>
> What are your thoughts on using a 'cobbler' user and group, setting
> the correct group permissions etc.

Cobbler needs to interact with /sbin/service and a few other things that 
root needs access to.    Particularly import runs createrepo because,
depending on how imported, rsync might be told to exclude some packages 
and it has to rebuild the index.   For instance, if importing from
an rsync mirror, one might know they didn't want Open Office translation 
packages and could save the space/bandwidth.

>
> The issues I was having when using the NAS / NSF mounts was that the
> import seemed to mess up the repodata xml files and an ugly python
> error ensues. ( no repos left) The issue seems to be with walking the
> file set after import.
Createrepo might not like NFS with the way you've mounted it.   This is 
likely.

>
> I apologise, I don't have the error output.
>
> Has anyone else run into similar issues when importing from a NFS
> source or the like?
I would just do "cobbler distro add" and "cobbler profile add" ... once 
you understnad those, that is really all cobbler is automating for you 
with import.

>
> Aaron
>
> On 4/23/07, Michael DeHaan <mdehaan at redhat.com> wrote:
>> Aaron Lippold wrote:
>> > Hello,
>> >
>> > I am having issues with the cobbler import --path=x stuff. I have an
>> > NFS mounted NAS device that I store all my expanded RHEL dvds on for
>> > ks installs. I have a mount point on the cobbler server that will
>> > allow me to have a bit faster access to the data than my the main
>> > server disk will allow and I want to take advantage of it. When I do a
>> > 'cobbler import --path=/path/to/stuff --mirror-name=glorp' as the man
>> > page suggests, it still copies the source files to
>> > /var/www/cobbler/ks_mirror. The man pages, if I understand, suggests
>> > that it won't copy it over, but just point to this. Am I mistaken?
>> >
>> > I would assume that this case, i.e. mass storage, was the reason for
>> > the --path option.
>> The "--path" used to do the "no copy" thing you mentioned above, but it
>> couldn't plug in the "tree" location in the kickstart automatically, and
>> this was a source for much confusion on the lists.   To reduce that
>> confusion, as well as to make "import" more automagical, "--path" now is
>> just an alias for "--mirror".  I'll update the manpage if that's 
>> misleading.
>>
>> So, in more recent versions of cobbler, "import" always copies files
>> over to /var/www/cobbler/ks_mirror.   The reason for this is to ensure
>> that the contents of those files are serveable for network installs --
>> yes, nfs:// tree
>> support does exist in kickstart, but this way cobbler doesn't need to
>> understand all of the NFS parameters and mounts -- plus we know the
>> files in question are local to cobbler.    What you can do is either:
>>
>> (A) make /var/www/repo_mirror be a symlink to storage on your NAS
>> device, and then run import to load DVDs onto your NAS device.   Note
>> that there can be weird issues with Apache serving off NFS symlinks,
>> especially with SELinux, so this is probably not your best option.
>>
>> or
>>
>> (B)  use "cobbler distro add" and "cobbler profile add" and not
>> "import", and then just set up your kickstart tree URLs manually in your
>> kickstarts to point to the NAS device.   This will do exactly the same
>> thing with just a little more work on your part.
>>
>> cobbler distro add --name=distroname --kernel=/mnt/nasdevice/.../vmlinuz
>> --initrd=/mnt/nasdevice/..initrd.img 
>> --ksmeta="tree=nfs://magic/nfs/path"
>> cobbler profile add --name=profilename --profile=distroname
>> --kickstart=/path/to/kickstart
>> cobbler sync
>>
>> FYI -- these types of questions are best posted to et-mgmt-tools so
>> everyone can benefit from seeing the answers.
>>
>> --Michael
>>
>>
>
> _______________________________________________
> et-mgmt-tools mailing list
> et-mgmt-tools at redhat.com
> https://www.redhat.com/mailman/listinfo/et-mgmt-tools