On Jun 6, 10:38 am, "William Stein" <[EMAIL PROTECTED]> wrote:
> That doesn't make any sense. I haven't changed anything in the spkg-install
> for
> the sage package that would cause that behavior. Look at the script
> devel/sage/spkg-install
> which is run when SAGE upgraded your library.
On 6/6/07, Michel <[EMAIL PROTECTED]> wrote:
>
> Ok I see. I wasn't aware that one sage process
> (your "server process") could serve multiple users.
> I will wait to see how things develop.
> ===
> In the setup I was planning it is definitely not true that any user
> c
Ok I see. I wasn't aware that one sage process
(your "server process") could serve multiple users.
I will wait to see how things develop.
===
In the setup I was planning it is definitely not true that any user
can kill
the server process. I wanted to have a bunch of us
On 6/6/07, alex clemesha <[EMAIL PROTECTED]> wrote:
> > Yes. To reiterate, the right solution is that the individual
> > worksheets(or at least SAGE users) all run as separate
> > users distinct from the notebook process (and -- ideally --
> > from each other). They then would not have permiss
> Yes. To reiterate, the right solution is that the individual
> worksheets(or at least SAGE users) all run as separate
> users distinct from the notebook process (and -- ideally --
> from each other). They then would not have permissions
> to kill the server. In particular, with this model --
On 6/6/07, Michel <[EMAIL PROTECTED]> wrote:
> If I understand you correctly we are saying exactly the same thing
>
> What I did was implementing a "server process" as a trivial shell
> script.
> The user (one user in my case) can kill his
> own copy of sage but not the server process since t
I agree with what Tom said about how hard it is to write the css well.
I tried to fix a major issue with the sidebar regarding the size of
the html files and I just couldn't get it to look very well.
On 6/6/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> On some browsers, you can't even see
On some browsers, you can't even see the scroll bars! The "official channel"
to discuss the notebook is sage-devel. The unofficial channel is usually email
between William, Alex, Dorian, Timothy and myself (and sometimes Robert Miller,
and I think I'm forgetting somebody).
The CSS of the not
If I understand you correctly we are saying exactly the same thing
What I did was implementing a "server process" as a trivial shell
script.
The user (one user in my case) can kill his
own copy of sage but not the server process since that runs as root.
The server process can then restart th
On 6/6/07, Michel <[EMAIL PROTECTED]> wrote:
>
> Are you sure what you say is true?
Yes. To reiterate, the right solution is that the individual
worksheets(or at least SAGE users) all run as separate
users distinct from the notebook process (and -- ideally --
from each other). They then would
Are you sure what you say is true?
I mean doing
sage: import os
sage: os.system("whoami")
server2
sage: os.system("ps -u server2")
PID TTY TIME CMD
6418 ?00:00:00 sh
6419 ?00:00:00 sage
6425 ?00:00:00 sage-sage
6439 ?00:00:00 sage-run
6440 ?
On 6/6/07, Nils Bruin <[EMAIL PROTECTED]> wrote:
>
> When I did a sage -upgrade, it ran into the following problem for the
> installation of the documentation:
>
> Extracting package /usr/local/sage/default/spkg/standard/
> doc-2.6.spkg ...
> -rw-r--r-- 1 nbruin nbruin 3121152 Jun 5 16:25 /usr/lo
On 6/6/07, Michel <[EMAIL PROTECTED]> wrote:
> Yes, I agree. But one has to guard against the user
> killing his own sage process. Is it possible to prevent this?
>
> If this is not possible then any solution will be basically
> equivalent to mine (restarting the sage process of the user).
> Imple
When I did a sage -upgrade, it ran into the following problem for the
installation of the documentation:
Extracting package /usr/local/sage/default/spkg/standard/
doc-2.6.spkg ...
-rw-r--r-- 1 nbruin nbruin 3121152 Jun 5 16:25 /usr/local/sage/
default/spkg/standard/doc-2.6.spkg
doc-2.6/
doc-2.6/
Yes, I agree. But one has to guard against the user
killing his own sage process. Is it possible to prevent this?
If this is not possible then any solution will be basically
equivalent to mine (restarting the sage process of the user).
Implemented within sage of course instead of a shell
script.
On Jun 6, 2007, at 10:38 AM, William Stein wrote:
>
> On 6/5/07, Nick Alexander <[EMAIL PROTECTED]> wrote:
>>
>> Hello all,
>>
>> sage -upgrade seems to be blowing away my committed hg patches that
>> have not been pushed to William yet.
>
> That doesn't make any sense. I haven't changed anythi
Hi,
The better solution -- in the long run -- is that each SAGE worksheet
process starts as a different more limited user. Unfortunately, this
will require significant work to implement -- we'll likely do it
at SD4 next week.
William
On 6/6/07, Michel <[EMAIL PROTECTED]> wrote:
>
> Yep this s
Yep this solution seems to work quite well. My son remarked
that when restarting sage it is necessary to also kill all processes
run by sageuser. Otherwise sageuser could start a process which
would be on the lookout for new instances of sage and kill
these also!
Michel
On Jun 6, 6:40 pm, Mich
On 6/5/07, Nick Alexander <[EMAIL PROTECTED]> wrote:
>
> Hello all,
>
> sage -upgrade seems to be blowing away my committed hg patches that
> have not been pushed to William yet.
That doesn't make any sense. I haven't changed anything in the spkg-install for
the sage package that would cause tha
On Jun 6, 2:04 pm, Michel <[EMAIL PROTECTED]> wrote:
> Input from my son who is fascinated by security.
>
> On my setup at least the notebook user can
> kill the sage binary, needing manual intervention
> to start it again.
>
> How to guard against that?
>
> Michel
Well instead of starting
su
Input from my son who is fascinated by security.
On my setup at least the notebook user can
kill the sage binary, needing manual intervention
to start it again.
How to guard against that?
Michel
--~--~-~--~~~---~--~~
To post to this group, send email to sag
21 matches
Mail list logo
