How do I assign trustee rights from within a script?

I'm doing a file migration from NetWare to my OES 2018.3 server. I have all the files but no trustee rights. This is not unexpected, but that's another lengthy story.

rights -f /media/nss/DATA/VOL1/Office -r RWCEMF trustee temp2.OU

I'm using the rights command to assign the trustee rights. When I run the command in a PuTTY session, it works; when I try to use a script, it doesn't.

I know next to nothing about creating linux scripts, although what I'm trying to do shouldn't be difficult. 

The first issue is that the result shows "No such file or directory". Unamused

__________
Kevin Boyle, 
Knowledge Partner

Calgary, Alberta, Canada

Parents
  • 0  
    a file migration from NetWare to my OES 2018.3

    And now I'm doing the same thing.  How did you get the rights off of NetWare?   The trustee command?  Or other?

    ________________________

    Andy of KonecnyConsulting.ca in Toronto
    Please use the "Like" and/or "Verified Answers" as appropriate as that helps us all.

  • Suggested Answer

    0   in reply to   
    How did you get the rights off of NetWare?

    It was a convoluted process...

    My OES 18.3 server is in a new tree.

    My NSS files were all that remained to be migrated from my NetWare server.

    I attempted this migration on at least three previous occasions, first to my OES 2015 server where the migration utilities had so many bugs as to make the migration impossible. I encountered similar issues attempting to migrate to OES 18 and 18.1.

    I had a new workstation deployment I had to complete. The workstations were to be members of my new DSfW domain. For users to be able to login to their new Windows workstations I needed my eDirectory users migrated to my new tree. I was able to complete that part of the migration.

    I quickly learned that I was unable to authenticate to the Windows workstations using a domain account. After working with Micro Focus tech support for weeks, after multiple support sessions, after collecting multiple packet traces, we were no further ahead until I noticed there was one account that would authenticate. It was a new account I had created. Since tech support didn't have a clue why I couldn't authenticate with my migrated accounts, the solution was simple: delete the migrated accounts and manually create new ones (~50). A year later I found a TID explaining that migrated accounts were missing certain attributes... but back to my NSS migration.

    My NetWare tree and my OES tree had the same users but the users in my OES tree were not the same trustees as the users in my NetWare tree. Scream

    I couldn't migrate my trustees! Furthermore, they were a mess!

    • Users typically showed trustee rights inherited from multiple sources.
    • Multiple users were granted RF rights a the "O" level.
    • Undocumented IRF were scattered throughout the file structures to negate certain users' unrestricted access.
    • No one had ever considered using groups to assign trustee rights.
    • Some directories had specific attributes assigned. Of course, they were undocumented too.

    This is what happens over a twenty year period of "evolution". I needed to document this mess before deciding how to deal with it!

    My NetWare 6.5 server is a VM: one processor; 4 GB memory; 750 GB NSS data. I decided it would be easier to analyze the NSS files from the OES server which had multiple processors, lots of memory, and newer versions of all the utilities I would need. I cloned the two NetWare vmdk disks and attached them to the OES server. 

    I created a spreadsheet for each volume with multiple worksheets:

    • Remote Manager - Volume Trustee report
    • IRFs
    • Directory Attributes

    As it turned out, there were only a handful of IRFs and custom attributes. The office manager determined that the thirty trustees could each be assigned to one of ten groups and the forty top level folders on the main data volume each had one or two trustee groups.

    • I used the spreadsheet to construct rights commands to assign trustee rights and IRFs.
    • I attached a fresh copy of the NetWare vmdk files to the OES server.
    • I ran the linux cp command on the OES server to copy the NetWare NSS files to a new NSS pool, keeping the original attributes (dates, time, etc.).
    • I ran the commands from the spreadsheet to assign Trustee rights, IRFs and attributes.

    ...and that was my NSS file migration (without migrating any trustees).

    __________
    Kevin Boyle, 
    Knowledge Partner

    Calgary, Alberta, Canada

Reply
  • Suggested Answer

    0   in reply to   
    How did you get the rights off of NetWare?

    It was a convoluted process...

    My OES 18.3 server is in a new tree.

    My NSS files were all that remained to be migrated from my NetWare server.

    I attempted this migration on at least three previous occasions, first to my OES 2015 server where the migration utilities had so many bugs as to make the migration impossible. I encountered similar issues attempting to migrate to OES 18 and 18.1.

    I had a new workstation deployment I had to complete. The workstations were to be members of my new DSfW domain. For users to be able to login to their new Windows workstations I needed my eDirectory users migrated to my new tree. I was able to complete that part of the migration.

    I quickly learned that I was unable to authenticate to the Windows workstations using a domain account. After working with Micro Focus tech support for weeks, after multiple support sessions, after collecting multiple packet traces, we were no further ahead until I noticed there was one account that would authenticate. It was a new account I had created. Since tech support didn't have a clue why I couldn't authenticate with my migrated accounts, the solution was simple: delete the migrated accounts and manually create new ones (~50). A year later I found a TID explaining that migrated accounts were missing certain attributes... but back to my NSS migration.

    My NetWare tree and my OES tree had the same users but the users in my OES tree were not the same trustees as the users in my NetWare tree. Scream

    I couldn't migrate my trustees! Furthermore, they were a mess!

    • Users typically showed trustee rights inherited from multiple sources.
    • Multiple users were granted RF rights a the "O" level.
    • Undocumented IRF were scattered throughout the file structures to negate certain users' unrestricted access.
    • No one had ever considered using groups to assign trustee rights.
    • Some directories had specific attributes assigned. Of course, they were undocumented too.

    This is what happens over a twenty year period of "evolution". I needed to document this mess before deciding how to deal with it!

    My NetWare 6.5 server is a VM: one processor; 4 GB memory; 750 GB NSS data. I decided it would be easier to analyze the NSS files from the OES server which had multiple processors, lots of memory, and newer versions of all the utilities I would need. I cloned the two NetWare vmdk disks and attached them to the OES server. 

    I created a spreadsheet for each volume with multiple worksheets:

    • Remote Manager - Volume Trustee report
    • IRFs
    • Directory Attributes

    As it turned out, there were only a handful of IRFs and custom attributes. The office manager determined that the thirty trustees could each be assigned to one of ten groups and the forty top level folders on the main data volume each had one or two trustee groups.

    • I used the spreadsheet to construct rights commands to assign trustee rights and IRFs.
    • I attached a fresh copy of the NetWare vmdk files to the OES server.
    • I ran the linux cp command on the OES server to copy the NetWare NSS files to a new NSS pool, keeping the original attributes (dates, time, etc.).
    • I ran the commands from the spreadsheet to assign Trustee rights, IRFs and attributes.

    ...and that was my NSS file migration (without migrating any trustees).

    __________
    Kevin Boyle, 
    Knowledge Partner

    Calgary, Alberta, Canada

Children
No Data