Re: bugzilla, smugzilla

Nikodemus Siivola <nikodemus <at> random-state.net> writes:

> Since savannah and sf seem to get away with mandating a single
> bug-tracking software, we probably can as well -- absent
> demonstratable need for multiple solutions.

Hm.  I'm not sure about this anymore.  A bugzilla installation for each
project sounds very heavy weight.  I'll have to check out the other
bugtrackers to see if they are more lightweight.

> Btw, how's allegroserve coming along?

Having some problems; think I need to apply a patch somewhere.

Erik.

ftp updates

it would seem that the directory /project/bese/ftr is not getting
copied over to $PUBLICFTP/pub/project/bese.

--

-- 
-Marco
Ring the bells that still can ring.
Forget your perfect offering.
There is a crack in everything.
That's how the light gets in.
     -Leonard Cohen

symlinks in /var/www

Ok, after popular demand, I have removed the cron approach to updating
the www directories for the projects.
/project/≤project-name>/public_html is now being symlinked to from
/var/www/project/≤project-name> so any changes you make will be instant.

I'm thinking about doing the same with FTP but that would mean I
couldn't do the chroot anymore (unless I'm missing something) and I'm
not sure we want to do that yet.

Erik.

Re: bugzilla, smugzilla

Nikodemus Siivola <nikodemus <at> random-state.net> writes:

> Btw, how's allegroserve coming along?

At the moment I'm getting errors from paserve CVS:

  ;; Loading #p"/custom/sys/portableaserve/portableaserve-cvs-20030908/acl-compat/cmucl/acl-mp.x86f".

  Error in function COMMON-LISP::FOP-EVAL-FOR-EFFECT:
     Attempt to load a file having a compile-time read error.

Which probably comes from:

  File: /custom/sys/portableaserve/portableaserve-cvs-20030908/acl-compat/cmucl/acl-mp.lisp 

  In: DEFUN MAKE-PROCESS 
    (MULTIPROCESSING:MAKE-PROCESS NIL :NAME NAME :RUN-REASONS ...) 
  Warning: :RUN-REASONS is not a known argument keyword. 
  Warning: :ARREST-REASONS is not a known argument keyword. 
  Warning: :INITIAL-BINDINGS is not a known argument keyword. 

  Converted MAKE-PROCESS. 
  Compiling DEFUN MAKE-PROCESS:  
  Converted PROCESS-KILL. 
  Compiling DEFUN PROCESS-KILL:  
  Converted MAKE-PROCESS-LOCK. 
  Compiling DEFUN MAKE-PROCESS-LOCK:  
  Converted WITH-PROCESS-LOCK. 
  Compiling DEFMACRO WITH-PROCESS-LOCK:  
  Byte Compiling Top-Level Form:  

Re: ftp updates

Maybe /var/ftp/pub/project/≤name< should be symlinks to /project/≤name>/ftp,
and likewise for public_html?

Cheers,

 -- Nikodemus

Re: ftp updates

Nikodemus Siivola <nikodemus <at> random-state.net> writes:

> Maybe /var/ftp/pub/project/≤name< should be symlinks to
> /project/≤name>/ftp, and likewise for public_html?

You probably missed my other email:

  Ok, after popular demand, I have removed the cron approach to updating
  the www directories for the projects.
  /project/≤project-name>/public_html is now being symlinked to from
  /var/www/project/≤project-name> so any changes you make will be
  instant.

  I'm thinking about doing the same with FTP but that would mean I
  couldn't do the chroot anymore (unless I'm missing something) and I'm
  not sure we want to do that yet.

Still not sure about that one.  Perhaps I'm too cautious about security.
If none of you get a bad feeling in your stomachs from running the FTP
server without a chroot I'll go ahead and do it.

Erik.

Re: ftp updates

On Thu, Sep 11, 2003 at 05:11:01PM -0400, Erik Enge wrote:

> You probably missed my other email:

I didn't. It must be taking the scenic route ... ;)

>   I'm thinking about doing the same with FTP but that would mean I
>   couldn't do the chroot anymore (unless I'm missing something) and I'm
>   not sure we want to do that yet.

Ah. Didn't think of chroot issues. What about doing it the other way
around: /project/≤name>/ftp -> /var/ftp/pub/project/≤name>?

Cheers,

 -- Nikodemus

_______________________________________________
Clo-devel mailing list
Clo-devel <at> common-lisp.net
http://common-lisp.net/mailman/listinfo/clo-devel

Re: ftp updates

Nikodemus Siivola <nikodemus <at> random-state.net> writes:

> Ah. Didn't think of chroot issues. What about doing it the other way
> around: /project/≤name>/ftp -> /var/ftp/pub/project/≤name>?

Ah, didn't think of that.  :) Ok, /project/≤name>/ftp is a symlink to
/var/ftp/pub/project/≤name>.  Is there anything more but a username you
need now, Andreas?

Erik.

Re: ftp updates

Erik Enge <erik <at> nittin.net> writes:

> Ah, didn't think of that.  :) Ok, /project/≤name>/ftp is a symlink to
> /var/ftp/pub/project/≤name>.

/project/PROJECT directories are owned by the same group as the
project members, this allows members to create files/directories in
the project directories. I don't know if you want to allow this or
not.

/project/PROJECT/ftp is owned by ftp.nogroup (not the symlink, the
actual directory) which makes it impossible for members of the project
group to copy/delete files to/from the ftp directory.

--

-- 
-Marco
Ring the bells that still can ring.
Forget your perfect offering.
There is a crack in everything.
That's how the light gets in.
     -Leonard Cohen

Re: ftp updates

Marco Baringer <mb <at> bese.it> writes:

> /project/PROJECT directories are owned by the same group as the
> project members, this allows members to create files/directories in
> the project directories. I don't know if you want to allow this or
> not.

I don't know.  What do y'all think?

> /project/PROJECT/ftp is owned by ftp.nogroup (not the symlink, the
> actual directory) which makes it impossible for members of the project
> group to copy/delete files to/from the ftp directory.

That's a bug.  Fixed; thanks for reporting.

Erik.