Conference iosg::all-in-1_v30

Hello again,

Good grief - it seems to be contagious.
Another customer has also managed to delete A1$SCRIPT - only this time the 
profile entry was intact - but the doc*.dirs & the main drawer have gone.

What's the best thing to do here?
Re-create user from scratch - or re-seed - or wot?


Thanks & regards,

Chele

    Chele,
    Sorry, no 'pithy sayings'! But, can you get us a pointer to the delete
    logs for these cases (in OA$LOG:). Delete user has a lot of checks in
    it now, and I'd like to see exactly where it decided not to go any
    further. Also, I'm not quite sure what they were doing with A1$SCRIPT?
    Were they trying to delete this entry or was it accidental?
    Cheers
    DaveT

    A1$SCRIPT doesn't have anything special about its profile record, and
    its account will probably be empty. Just recreate the profile record by
    copying the fields (with suitable changes for disc names etc.) form
    another system. You could use part of the script that the installation
    uses: OA$LIB:UPGRADE_PROFILE.SCP, but you'll have to edit a bit to fill
    in the DIRECT field with a hardwired value.
    
    Other problems about not setting drawer will probably be due to the
    partition seeding evaporating, which you can fix with a single reseed.
    
    As Dave says, finding out why this happens is most important!
    
    Graham

Hello again,

In both cases the deletion was accidental - both customers are a bit vague 
with the details, but it appears that they were attempting to do 2 user 
deletions, the first goes through, then the second seems to default (they think)
to A1$SCRIPT

More details when I can get them...

Chele

'ello,

Sounds like in one case the customer did a Delete User on A1$SCRIPT, Some 
files, deleted, some not, then delete failed. Profile still intact. Later on 
they seem to have done a Delete Profile on it (some months later) (Logs for 
this probably NOT available)

'tother customer did a Delete User, but seems to have passed on a Delete 
Profile. Has some files & not others - I may have more luck getting a log file 
here.


Chele

G'day,

Looks like only the files owned by [A1$SCRIPT] (eg, the doc*.dirs) get zotted.
Files owned by [ALLIN1] don't get zotted, which I guess is where the Delete 
User starts to fail....

Fun, Isn't it?

 
Chele

    RE .4
    
    When you've deleted an account from MUA, the context block is reset to
    the first account in the profile, which is almost certainly A1$SCRIPT.
    So if they forgot to select another account before doing the next
    Delete....
    
    Perhaps we should make "system type" accounts harder to delete :-)
    
    Graham

    Hi Graham,
    
    At present we 'protect' MANAGER, batch_account, manager_accnt,
    holding_accnt (all from POLICIES), BOOT, POSTMASTER, IVP - perhaps
    we should add to this list? A1$SCRIPT,... any more?
    
    DaveT

	Hi Dave
    
>    At present we 'protect' MANAGER, batch_account, manager_accnt,
>    holding_accnt (all from POLICIES), BOOT, POSTMASTER, IVP - perhaps
>    we should add to this list? A1$SCRIPT,... any more?

	PLEASE add OAFC* to your list.  With the current corporate paranoia
	concerning Inspect,  we are seeing sites delete these because Inspect
	tells them to. Now if we could build in a trap in Authorize ...
    
	Thanks

	John

The BOOT account is long dead and should be removed from current versions
of ALL-IN-1.  I think it went away around v2.2 or so.

	-Al

    Al,
    
    The v2.3 documentation "stongly recommended" the removal of the BOOT
    account for 'security reasons' so I would have thought it was sort of
    inconsistent for us to be preventing customers from deleting it in v3.0
    
    John,
    
    Dave's code brilliant as it is is probably limited to protecting
    customers from deleting ALL-IN-1 accounts - since the OAFC* things
    don't have ALL-IN-1 accounts it might be a little too much to expect
    from Delete User.
    
    Regards,
    
    Andrew.D.Wicks

	Sorry Andrew, I knew that.  Don't know what I was thinking about.

	Give me another "mark"  :-)

    no problems. BOOT will go from DU. 
    (logic in your reply, Andrew, is a winner!)
    cheers
    dt

Hello again,

In the unlikely event that anyone still wants the deletion log, a copy can be 
found on MSOTIS::DKA300:[BURT.PUBLIC.ALL-IN-1]OA$MANAGER_DELETE.LOG_Q40371;

Thanks & regards,

Chele

    Hi All,
    
    A customer has deleted A1$SCRIPT and I have managed to re-create all
    the sub-directories ie [.DOC%] etc. and have made sure that the file
    ownerships are correct.
    
    I than ran the OA$LIB:OAFC$SEED_USER.SCP making sure that I have the
    #OAFC_SEED_USER was loaded with "A1$SCRIPT" and that the profile record
    is unlocked.  When I run the script I get the following error message:
    
    %OA-W-INVGET, Symbol "PART$MAINT:#PARTITION.%CLOSE[#PARTITION]" not
    found. 
    
    Can someone tell me what is happening ? I had searched PARTITION.DAT
    and could not find the A1$SCRIPT string using the OpenVMS SEARCH
    command.
    
    Finally whatever happened to the confirmation prompts that we had in
    ALL-IN-1 IOS 2.4 ?  It's all very well asking users if they want to
    delete the Mail directory etc. we need the confirmation to delete
    prompt back please.  Number of calls we have regarding account deletion
    is getting a bit too much !!!  Let's "Practice safe deletion" please
    and put A1$SCRIPT on the list of protected accounts at least.
    
    Regards,
    
    Sunil

    fyi:
    
    Please see 3213 for another example of this problem. I thought it was
    unknown, based on the response I got. 
    
    Bruce

    Hi Bruce,
    
    My problem is that I can't seed the drawer and have done all that is
    required.  What does the error mean and how do I get out of it ?
    
    Regards,
    
    Sunil