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@xxxxxxxxxx> 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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
