Bug 26132 - please add net-fs/ coda 6.0.3
|
Bug#:
26132
|
Product: Gentoo Linux
|
Version: 1.4
|
Platform: All
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: enhancement
|
Priority: P2
|
|
Resolution: FIXED
|
Assigned To: griffon26@gentoo.org
|
Reported By: flokno@gmx.net
|
|
Component: Ebuilds
|
|
|
URL:
http://www.coda.cs.cmu.edu/
|
|
Summary: please add net-fs/ coda 6.0.3
|
|
Keywords: EBUILD
|
|
Status Whiteboard:
|
|
Opened: 2003-08-07 09:36 0000
|
if possible!
coda new version 6.0.1
from 2003-07-05
thanks!
Reproducible: Always
Steps to Reproduce:
Hi,
I'm working on a new ebuild for 'net-fs/coda', which will replace
'net-fs/coda-server' and 'net-fs/coda-client'. Basically there is no point in separating
the ebuilds any more, since the same source tree needs to be built for both the client
and server portions, both of which are now housed in the same .tar.gz. This helps
make coda more consistant with the overall net-fs/ tree (nfs does not separate the
client/server portions, etc).
I've also updated the net-fs/coda dependencies and have working ebuilds for
them (which I will post below): sys-libs/lwp, sys-libs/rvm, and net-libs/rpc2. They are
just modifications of the existing ebuilds; however, I have not tested them against the
current net-fs/coda-* so I'm not sure if they'll work with older coda (they should...?).
Once I've fixed the default coda init scripts to work with gentoo, I'll post the ebuild.
Besides that, it seems to be working.
-- mcf
P.S. coda 6.0.2 is the latest now.
Created an attachment (id=15956) [details]
ebuild for the latest Coda FS kernel module, net-fs/coda-kernel
We have to use a new kernel module for version 6.0 Coda FS to work. Even
2.6-test3 has the older (version 2) Coda structs. This may change in the
future, so we can get rid of this ebuild...
Hi... sat down this weekend to play with Coda and just happened to run across
this bug.
Just curious if these ebuilds are ready for use yet, and if so, why aren't
they in Portage? I'd really like to be able to use the new Coda (since I
can't seem to get the 5.9 ebuilds to work...). I'd be happy to test things
if that would help any.
Thanks!
lwp, rvm and rpc2 are updated in portage.
So now all we need is the ebuild, Michael, for coda6
Created an attachment (id=20799) [details]
net-libs/rpc2-1.20 (Update)
New net-libs/rpc2 ebuild. I'm not really sure what changed, since the ChangeLog
file is empty. But probably this fixes some bugs somewhere...
Created an attachment (id=20800) [details]
net-fs/coda-6.0.3 ebuild (new)
Sorry, I have been sitting on this for a while. Real life work has kinda taken
over. I haven't had a chance to test this extensively, but it appears to work.
If
anyone could give me some feedback, I would appreciate it. :)
The contents of net-fs/coda/files will follow (just the initscripts)...
Created an attachment (id=20802) [details]
net-fs/coda/files/coda-update initscript (new)
coda-update (called 'update' in coda, but I renamed it to 'coda-update' because
'update' is a little vague). Tested and working...
Created an attachment (id=20803) [details]
net-fs/coda/files/codasrv initscript (new)
The codasrv initscript. I am not sure if this is 100% working, and I don't have
time atm to set up a 6.0 coda server to test it with. If someone could try
this out for me, I would appreciate it. It should work, as it is based
off of the regular coda initscripts.
Created an attachment (id=20804) [details]
net-fs/coda/files/venus initscript (new)
venus initscript. Testing and works. venus requires a working codafs kernel
module, so either use the ebuild above for net-fs/coda-kernel, or compile in
one from the latest 2.6-test tree (which includes the new 128-bit coda6
support)
I tried out the ebuild and there were a few things I noticed:
1) coda depends on net-fs/coda-kernel which is not something virtual
Because I am running kernel 2.6, I don't need (in fact can't even use)
coda-kernel. I suppose kernel 2.6 and net-fs/coda-kernel should provide
virtual/coda-kernel and net-fs/coda should depend on it.
2) Starting codasrv doesn't seem to complete. I can see in /vice/srv/SrvLog
that the server has been started, so I think it's just a "with or without &"
issue.
3) I could not find any information about the ports that are used between
coda servers. I needed it for opening up the right ports in my firewall.
Not everything is working yet, but so far it seems only UDP port 369 and
36089 are used. 36089 is not added to /etc/services by the setup, so I
don't know what it's for.
4) I found the whole setup pretty complicated. I was asked quite a few
questions for which not only I didn't know the answer, but also didn't
know what they were asking =]
I suppose a gentoo guide that provides the information found in this
tutorial http://www.linuxplanet.com/linuxplanet/tutorials/4481/1/
and that also explains why you would want to do what you're doing there,
could be quite useful.
I may get time to play with this.
I got the following on the following on coda-6.0.3 ebuild (with removed
coda-kernel dependancy). Cannot see any '[' in worker.cc near this line. Anyone
else get this?
make[2]: Entering directory
`/var/tmp/portage/coda-6.0.3/work/coda-6.0.3/coda-src/librepair'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory
`/var/tmp/portage/coda-6.0.3/work/coda-6.0.3/coda-src/librepair'
make -C venus all;
make[2]: Entering directory
`/var/tmp/portage/coda-6.0.3/work/coda-6.0.3/coda-src/venus'
g++ -fno-exceptions -fcheck-new -Wall -MD -DHAVE_CONFIG_H -I.
-I/var/tmp/portage/coda-6.0.3/work/coda-6.0.3/include
-I/var/tmp/portage/coda-6.0.3/work/coda-6.0.3 -O2 -mcpu=i686 -pipe -DVENUS
-DTIMING -DVENUSDEBUG -DRVM_USELWP -c -o fso_cfscalls2.o fso_cfscalls2.cc
g++ -fno-exceptions -fcheck-new -Wall -MD -DHAVE_CONFIG_H -I.
-I/var/tmp/portage/coda-6.0.3/work/coda-6.0.3/include
-I/var/tmp/portage/coda-6.0.3/work/coda-6.0.3 -O2 -mcpu=i686 -pipe -DVENUS
-DTIMING -DVENUSDEBUG -DRVM_USELWP -c -o worker.o worker.cc
worker.cc: In function `void WorkerInit()':
worker.cc:782: error: parse error before `[' token
make[2]: *** [worker.o] Error 1
make[2]: Leaving directory
`/var/tmp/portage/coda-6.0.3/work/coda-6.0.3/coda-src/venus'
make[1]: *** [venus] Error 2
make[1]: Leaving directory
`/var/tmp/portage/coda-6.0.3/work/coda-6.0.3/coda-src'
make: *** [coda-src] Error 2
!!! ERROR: net-fs/coda-6.0.3 failed.
!!! Function src_compile, Line 37, Exitcode 2
!!! emake failed
Created an attachment (id=25526) [details]
files/coda-6.0.4-iowr.patch
Was a problem with its interaction with kernel headers >=2.6*. This is fixed in
cvs so will be longer required next release. (Thanks Michael for the pointers)
Coda does a few ugly FHS things. Below are my planned corrections.
User mounting directory
/coda -> /mnt/coda
Lots of client stuff
/usr/coda/... -> As is -existance here is tolerated at the moment
Server side authentification and configuration
/vice -> /var/lib/vice (maybe /srv later after GLEP)
Created an attachment (id=25906) [details]
coda-6.0.3.ebuild (update2)
mjc where you going to resubmit some init scripts. If you could maybe make a
/etc/conf.d/coda that has variables to indicate whether auth2,update and coda
are on the same server. Just a suggestion. Looking forward to submitting this
;-).
The other thing I want to do is automate the install. If anyone wants to
contribute to this section please do so.
Committed coda 6.0.3. Please test let me know how to automate the install more.
All constructive feedback welcome.
I'm just adding these comments as I walk through the setup.
Tell me if I'm asking too much =]
1) "You need to give me a uid (not 0) and username (not root)
for a Coda System:Administrator member on this server,
(sort of a Coda super user)"
At first I entered 1, but that was already used by System. I'm not sure if that is the same type of id that I entered here:
"Enter an id for the SCM server. (hostname griffon27)
The serverid is a unique number between 0 and 255.
You should avoid 0, 127, and 255."
Because there I entered 1 as well.
If I use 2 for the user, then there are no complaints.
2) "Are you ready to set up RVM? [yes/no] yes
What is your log partition?"
I know it is possible to use a file, but how? And what would be a logical place to put it?
3) "Where shall we store your file data [/vicepa]?"
Odd location
4) " - create your root volume: createvol_rep rootvolumename E0000100 /vicepa"
So I do that and then I'm asked:
"Do you wish this volume to be Backed Up (y/n)? [n]"
What does that mean? If I want the current state to be saved? Or if I want to always have a backup of the volume (similar to the reliability you get with raid1)?
5) I aborted vice-setup once, but that meant the server id in /vice/db/servers remained. After running vice-setup again, I now had 2 identical lines in that file causing the startup of the server to fail.
6) Somewhere I was asked to enter a path that is /vice by default. I left it like that, but I notice that the startup scripts assume I filled in /var/lib/vice
7) I can see that making the setup understandable for people who don't really know how coda works isn't very easy. It would probably require changes in coda files and as gentoo developers you'd probably rather not do that.
I think that even a 1 page document with an explanation of how the different parts (meta files, log files, actual files, /mnt/coda) work together would help tremendously. That together with a few lines in the style of the rest of the Gentoo documentation could guide any newbie through the imho rather complex coda setup.
Btw, thumbs up for your efforts.
I'm just adding these comments as I walk through the setup.
Tell me if I'm asking too much =]
>> You can ask whatever you want - whether you get it is another thing ;-) jk Will try to accomidate this as best I can.
1) "You need to give me a uid (not 0) and username (not root)
for a Coda System:Administrator member on this server,
(sort of a Coda super user)"
At first I entered 1, but that was already used by System. I'm not sure if that is the same type of id that I entered here:
>> Yep can create a "coda" user, grab its uid and push that in somehow.
"Enter an id for the SCM server. (hostname griffon27)
The serverid is a unique number between 0 and 255.
You should avoid 0, 127, and 255."
>> ok I could choose a number. I'm currently thinking of an /etc/coda/coda.config file that is piped into this script. This gives useers a change to meddle but still have a fairly standard config.
2) "Are you ready to set up RVM? [yes/no] yes
What is your log partition?"
>> This is the main bit that scared me.
I know it is possible to use a file, but how?
>> To make a general file look like a partition (block device):
>> Loopback file system on a file.
>>#dd if=/dev/zero of=/var/lib/coda/log bs=12M
>>Size?
>>#losetup /dev/loop/5 /var/lib/coda/log
>>and use /dev/loop/5 as the partition
>>
And what would be a logical place to put it?
>> /var/lib, /var/cache, /var/log(?) even. Once I find out what this is I can make a choice here.
3) "Where shall we store your file data [/vicepa]?"
Odd location
>> very. /var/lib/vice, /src/vice (as per comment 19)
4) " - create your root volume: createvol_rep rootvolumename E0000100 /vicepa"
So I do that and then I'm asked:
"Do you wish this volume to be Backed Up (y/n)? [n]"
What does that mean? If I want the current state to be saved? Or if I want to always have a backup of the volume (similar to the reliability you get with raid1)?
>> hmm very befusing.
5) I aborted vice-setup once, but that meant the server id in /vice/db/servers remained. After running vice-setup again, I now had 2 identical lines in that file causing the startup of the server to fail.
>> Point to note - reset on restart.
6) Somewhere I was asked to enter a path that is /vice by default. I left it like that, but I notice that the startup scripts assume I filled in /var/lib/vice
>> Yep will somehow have to use that in the setup too.
7) I can see that making the setup understandable for people who don't really know how coda works isn't very easy. It would probably require changes in coda files and as gentoo developers you'd probably rather not do that.
>> Try to avoid it but its often necessary. The main problem here is getting all required changes to be consistant.
I think that even a 1 page document with an explanation of how the different parts (meta files, log files, actual files, /mnt/coda) work together would help tremendously. That together with a few lines in the style of the rest of the Gentoo documentation could guide any newbie through the imho rather complex coda setup.
>> Currently thinging a config section so that "ebuild /usr/portage/net-fs/coda/coda-6.0.3.ebuild config" will set it up from /etc/coda/coda.config (which will contain lots of comments to guide though a setup).
>> Gotta agree with doco - currently its horrible. XML docs aren't that bad to write its just getting the text right.
Btw, thumbs up for your efforts.
>> Thank for giving it a go and for providing feedback.
================================
WORK TO BE DONE
Ebuild to create "coda" user.
Make a /etc/coda/coda.conf that contains good text description in comments and the real data for viceconfig uncommented below it.
Will feed this to vicesetup like:
sed -e "s/^#//g" -e "s/^$//g" /etc/coda/coda.conf | vicesetup
(may change this to a chat script later but first things first)
Ebuild to include a pkg_config section.
------------
If anyone feels like putting together a /etc/coda/coda.conf I'd appreciate it. Also if anyone has a current coda server setup some yardstick on sizes for things and what works and what doesn't would be great. Either that or someone to read the documentation fully and understand it (ok I'm just being lazy here).
Why I have to setup the server, when I only need the client? I've tried it with
"venus-setup <server-name> <cache-size>" and then wanted to start up the client
"/etc/init.d/venus start" - with this result:
* Please set up vice before starting the service...
* Please set up vice before starting the service...
* Please set up coda before starting the service...
* Please set up vice before starting the service...
* Please set up vice before starting the service...
But when I start "venus &" manually everything works fine - so I don't need the
server stuff for the client. Even if I change the init-script ("need net
codasrv" -> "need net") I get one "Please set up vice..." and I don't know why.
Ok, the one eerror I got yesterday was the missing /var/lib/vice/hostname ( it
was late ;) ). I set up this file but still get some errors if I try to start
up venus with the init script.
But this errors concern to the server part, which I don't need on this box. So
I deleted 'codasrv' in the depend-line in the init-script and now it works as
expected.
Maybe - if possible - there should be a switch (or an entry in an
/etc/conf.d-file) which decides whether to start the server or not.
Markus, the init scripts except you to use /var/lib/vice and not /vice, I think
that's the problem you were having with /var/lib/vice/hostname. But yeah, I was
wondering the exact same thing, why is codasrv a dependency? I have removed
this and venus appears to start okay but the client won't work for me at all. I
have tried it with the test server and with my own. The /mnt/coda folder is
always empty and if I try to write there, it always says read-only filesystem.
This discussion should probably move to the forums. There isn't much mention of
Coda there.
Created an attachment (id=34724) [details]
Patch removes venus' dependency on codasrv and /mnt/coda
This small patch removes the dependency that venus has on codasrv.
You do not have to run a coda server to use the venus client.
The other fix is to use umount coda (device) instead of umount /mnt/coda (mount
point), as the mount point is user-configurable.
More patches will follow for the server.
Created an attachment (id=34731) [details]
Coda server init scripts patch to remove hard coded paths
This patch removes the hard coded /var/lib/vice path and
takes the configured path from /etc/coda/server.conf instead.
The patch also changes the messages that are given if coda
has not been configured. Now they are consistent and they
suggest a course of action for the user.
I have not been able to fully test the server yet, because
for some reason codasrv does not exit. SrvLog looks ok, it
says the server was started, and SrvErr is empty.
Does anybody else have this problem?
I'm finally getting somewhere with this thing! Some urgent changes still need
to be made to the scripts though. First of all, stopping coda-update doesn't
work properly.
* Stopping coda-update...
cat: /hostname: No such file or directory
cat: /db/scm: No such file or directory [ ok
]
This is because the $vicedir variable is not remembered between when the
service is started and when the service is stopped so the check_config function
would have to be run for stopping as well as starting. An alternative would be
to simply check if rpc2portmap and /usr/sbin/updatesrv are running and shut
them down if they are.
In the codasrv script, the /usr/sbin/codasrv command is being used. The docs
say to use /usr/sbin/startserver instead. This does a few extra little nifty
bits that could be useful. The script is also not being stopped properly. This
should do the trick...
stop() {
ebegin "Stopping codasrv"
/usr/sbin/volutil shutdown
RUNNING="firstloop"
while [ -n "$RUNNING" ]
do
RUNNING=$(ps ax -o cmd | grep "/usr\/sbin\/startserver$")
sleep 2
done
eend $?
}
Previously codasrv was being stopped with start-stop-daemon before the volutil
command was run. This was not correct. Only volutil is necessary. The while
loop replaces the 'sleep 30' line. Now the script terminates as soon as the
server does.
I'm just getting settled in as gentoo developer and
have new versions of the init scripts ready. I just
have to make sure that I don't miss any of the QA
steps =]
When the new versions are in cvs (probably somewhere
in the next few days) I will add another comment to
this bug to let you know.
The updates are in cvs. If (some of) the people subscribed to this bug
can confirm that the issues raised here have been fixed, then I will
close this bug. Any new issues should then get their own bug.
I haven't tried the stuff in CVS but I can tell you that this line in
/etc/init.d/venus doesn't work for me.
umount -l coda &>/dev/null
I'm not sure why. I think it used to work. I was previously using
gentoo-dev-sources but now I'm using love-sources, maybe that has something to
do with it?
eval `grep "^mountpoint=" /etc/coda/venus.conf || echo mountpoint=/coda`
umount -l $mountpoint &> /dev/null
This works instead. I used /coda and not /mnt/coda because I believe Coda uses
/coda by default.
James, could you show me the output of mount (or at least the coda related
line)?
In my case it shows this:
coda on /mnt/coda type coda (rw)
umounting can be done with the dir as well as with the device.
By umounting the device you can make it independant of the mount point.
That's what I thought too but look.
hair root # mount | grep coda
coda on /mnt/coda type coda (rw)
hair root # umount coda
umount: coda: not mounted
Can you possibly give coda-6.0.6 a try?
That would tell me if it's coda or something else that won't allow umount coda.
Oh, my mistake.
Can I assume you can normally umount using the device name without problems?
Do you have another kernel handy for trying it out there to rule out love-sources
as the cause?
And finally, can you include the output of emerge --info in your reply?
Thanks.
emerge net-fs/coda works fine here (at least for the client venus).
Could you remove coda-client and coda-server ? This is very confusing to have all of these when you try to get started with coda.
Btw, great work for the ebuilds and scripts, they are quite good :)
Maurice, I tend to agree with removing coda-{server/client}. Can this be closed
soon.
The coda-client and coda-server ebuilds have been prepared for removal from
portage. They now help any users of 5.x (if there are any) move over to 6.x
and in a while I will remove those ebuilds alltogether.
I'm hereby closing this bug, because it has no longer anything to do with what
it was submitted for and most of the issues mentioned have been taken care of.
Please report any open issues in a new bug report.
