4 Bře
2009
4 Bře
'09
16:31
Mark J Elkins píše v Út 03. 03. 2009 v 18:38 +0200:
As suggested on http://fred.nic.cz/wiki/download:
For c/c++ components use configure, make, make install(root access)
commands.
For python components do as root 'python setup.py install'
On our production servers, we use ubuntu package repository on
archive.nic.cz for installation. Fedora packages repository is also
there but Gentoo repository is just in our plans. Your help in setting
up such repository would be helpful.
fred-manager
is script that can be used to install fred under local (non
system) user in one of his directories. This has a lot of advantages.
You can run many Fred installations concurrently, you can easily
uninstall it by just deleting and so on. We use this for unit tests, for
performance tests etc.
So for a production server - what does one do? - copy everything to "/" ???
Its a bug in Gentoo Package-management
..first I deleted omniORB
Then:-
# emerge omniorbpy -v
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild N ] net-misc/omniORB-4.0.5 USE="ssl" 0 kB
[ebuild N ] dev-python/omniorbpy-2.5 USE="ssl" 0 kB
...
then.. (at the end of installing omniorbpy-2.5)
* Detected file collision(s):
*
* /usr/lib/python2.5/site-packages/omniidl_be/__init__.pyc
* /usr/lib/python2.5/site-packages/omniidl_be/__init__.py
* net-misc/omniORB-4.0.5
* /usr/lib/python2.5/site-packages/omniidl_be/__init__.py
* /usr/lib/python2.5/site-packages/omniidl_be/__init__.pyc
*
* Package 'dev-python/omniorbpy-2.5' NOT merged due to file collisions.
ie - both packages are trying to own the same file - and Gentoo does not
like that.
Contents of one of the files is:
#
# Empty file to convince Python that this is a module.
#
netwisdom seems to be to delete the file - then (re)install omniorbpy-2.5.
The bug was fixed - but is back again - so this needs to be noted to
watch out for in Gentoo installs.
After this - I recompiled from scratch.
Results are towards the end of the email.
My Gentoo colleagues use more recent versions of omniORB (omniORB-4.1.3
and omniORBpy-3.3) which are available by adding 'net-misc/omniORB ~x86'
and 'dev-python/omniorbpy ~x86' to /etc/portage/package.keywords. They
didn't have any problems with those packages. I don't expect any
problems with version 4.0 but, using actual version is better.
Regarding 'cron' - on Gentoo - mortal users
can not cd into /var/spool/cron
$ ls -l /var/spool/
total 16
drwxr-x--- 4 root cron 4096 May 26 2008 cron
drwx--x--- 3 root lp 4096 Mar 2 17:47 cups
drwxr-x--- 6 mail mail 4096 Feb 2 20:05 exim
lrwxrwxrwx 1 root root 10 Feb 2 18:38 mail -> /home/mail
drwxrwxr-x 2 root mail 4096 May 26 2008 mail.dist
fred@fred ~ $ cd /var/spool/cron
-su: cd: /var/spool/cron: Permission denied
They can have a crontab though - if "/etc/cron.allow" has your name
and/or "/etc/cron.deny" does not (from the man page of crontab)
Thats using Paul Vixie's cron system.
OK, this is fred-manager false expectation that it's enabled by default.
We should do some check before adding job to user cron. If you enable it
you will get regular zone file generation.
I quote from the 'howto'
FRED is designed to run Linux (and was tested on Linux only), but will
probably run on any Unix operating system which meets the requirements.
FRED requires following additional software to be installed:
* Apache <http://httpd.apache.org> Apache web server 2.x
* PostgreSQL <http://www.postgresql.org> database version 8.x
* OmniORB <http://omniorb.sourceforge.net/> CORBA server version 4.0
or better
* Boost <http://www.boost.org/> C++ libraries version 1.20 or better
* libdaemon <http://0pointer.de/lennart/projects/libdaemon/>
libdaemon library
Opps - 5 packages - not 4.
You do have a "
* ... " as well - but that could be anything!
Now I see. I apology ourselves for 'how to' page. It's slightly outdated
and not all requirements are listed there. And some of then (libdaemon)
are not needed at all. To handle dependencies you have three ways:
* We created diagram of dependencies on
http://fred.nic.cz/attachment/wiki/attachments/component_schema.png
* You can check .spec files and setup.cfg files inside tarball packages
to see dependency package names for rpm based system and try to find
similar in your distribution
* You can go through step by step installation as you did and checks
should inform you about missing dependency - but as you found out , for
example dependency for omniorbpy in fred-pyfred si missing.
Remaining part of installation 'how to' si about 90% still actual but
'fred-manager' script should automate this installation at all so maybe
it's worth to check this script and gain some information from it.
Ran install again and this time - ended with:-
All done!
cat: /home/fred/local_named.template: No such file or directory
Ooops, this is really missing component and I forgot it when uploading
fred-manager script on website. I will have to update fred-manager
script and embed it inside somehow. I attached this file to this email
to allow you finish this installation.
As a recapitulation for what we should do regarding your findings :
- update dependency control of fred-pyfred to check for omniorbpy
- update installation of cron job for local user to check if this is
possible at all
- incorporate named start up script to fred-manager to be resolve
dependency on external file.
Jaromir