savannah-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Savannah-users] Unable to upload release tarball to Download Area


From: Asher Gordon
Subject: Re: [Savannah-users] Unable to upload release tarball to Download Area
Date: Thu, 04 Apr 2019 04:20:42 +0000

Bob Proulx wrote:
> I have gained an understanding now. I know what needs to be done to
> solve the problem. At root cause I had broken one of the cron scripts
> in moving it from system to system. It wasn't updating a timestamp
> which caused a monitoring script in the redirector to think the mirror
> was out of sync when it was not. It needs to look not at the absolute
> age but the relative age however. The reference should be the
> upstream source, which is known to the redirector, not the time now.
> And there needs to be a fallback when there are no mirrors.

That's pretty complicated! I also noticed that many of the directories
in https://download.savannah.nongnu.org/releases/ are empty. Is that
part of the migration?

> I remember
> there being new restrictions on file deletion that didn't exist
> before. Therefore sshfs might just not be allowed through the command
> filter at this time.

That's too bad. Is it possible it will be in the future? Or if not, is
there another way to perform more complex tasks in directories than
simply uploading files? Specifically, I have in mind creating symlinks.
I don't believe that is possible with scp. It would also be nice to be
able to delete files in case I accidentally upload the wrong file or
something.

> As you might imagine it isn't allowed to run arbitrary commands.
> Therefore all of the ssh commands are filtered through an sv_membersh
> filter before being allowed through.

Couldn't sv_membersh allow commands like mv, cp, rm, ln, and whatever
sshfs and co. need, but make sure that they only operate on the project
directory? Does each Savannah user get his/her own user/group? If not,
I think that may be a good idea so you could run more commands, but
only under the unprivileged user account. Of course, you should probably
call the users something like sv-user-USER where USER is the Savannah
username, otherwise a user named "root" would be very problematic.

I hope my suggestions help.

Asher



reply via email to

[Prev in Thread] Current Thread [Next in Thread]