Skip to main content

[archive] New problem when using access records

  • September 26, 2007
  • 14 replies
  • 0 views
D

[Migrated content. Thread originally posted on 25 September 2007]

I found the most common cause of problems when you set USE_UNIX_SHELL is the "interactive" stuff performed in user's login scripts (e.g. /home/bill/.bash_profile). Here's an example of how we've modified our login scripts to accommodate AcuConnect:-
# a shell started by acurcl (with USE_UNIX_SHELL=1) will skip over this:
if [ "$PS1" ]; then
    # shell is interactive, so put your interactive code here.
    # the following will loop endlessly if started via acurcl:
    while [ -z "fname" ]; do
        echo -n "What is your first name?  "
        read fname
    done
    echo "Hello $fname"
fi
# no more interactive code beyond here!

    14 replies

    D

    [Migrated content. Thread originally posted on 25 September 2007]

    I found the most common cause of problems when you set USE_UNIX_SHELL is the "interactive" stuff performed in user's login scripts (e.g. /home/bill/.bash_profile). Here's an example of how we've modified our login scripts to accommodate AcuConnect:-
    # a shell started by acurcl (with USE_UNIX_SHELL=1) will skip over this:
    if [ "$PS1" ]; then
        # shell is interactive, so put your interactive code here.
        # the following will loop endlessly if started via acurcl:
        while [ -z "fname" ]; do
            echo -n "What is your first name?  "
            read fname
        done
        echo "Hello $fname"
    fi
    # no more interactive code beyond here!
    I just set up two workstations that use access records to force a unix login name. The other workstations match a wild card and share one login name.

    The two workstations with unique access records flash the acuthin splash screen and then quit.

    It seems that this problem started when I set up an acurcl.cfg with the line "USE_UNIX_SHELL 1" to be able to pass some values to the program.

    Any help, suggestions, etc, would be greatly appreciated.

    BillG3
    D

    [Migrated content. Thread originally posted on 25 September 2007]

    I found the most common cause of problems when you set USE_UNIX_SHELL is the "interactive" stuff performed in user's login scripts (e.g. /home/bill/.bash_profile). Here's an example of how we've modified our login scripts to accommodate AcuConnect:-
    # a shell started by acurcl (with USE_UNIX_SHELL=1) will skip over this:
    if [ "$PS1" ]; then
        # shell is interactive, so put your interactive code here.
        # the following will loop endlessly if started via acurcl:
        while [ -z "fname" ]; do
            echo -n "What is your first name?  "
            read fname
        done
        echo "Hello $fname"
    fi
    # no more interactive code beyond here!
    I just set up two workstations that use access records to force a unix login name. The other workstations match a wild card and share one login name.

    The two workstations with unique access records flash the acuthin splash screen and then quit.

    It seems that this problem started when I set up an acurcl.cfg with the line "USE_UNIX_SHELL 1" to be able to pass some values to the program.

    Any help, suggestions, etc, would be greatly appreciated.

    BillG3
    D

    [Migrated content. Thread originally posted on 25 September 2007]

    I found the most common cause of problems when you set USE_UNIX_SHELL is the "interactive" stuff performed in user's login scripts (e.g. /home/bill/.bash_profile). Here's an example of how we've modified our login scripts to accommodate AcuConnect:-
    # a shell started by acurcl (with USE_UNIX_SHELL=1) will skip over this:
    if [ "$PS1" ]; then
        # shell is interactive, so put your interactive code here.
        # the following will loop endlessly if started via acurcl:
        while [ -z "fname" ]; do
            echo -n "What is your first name?  "
            read fname
        done
        echo "Hello $fname"
    fi
    # no more interactive code beyond here!
    Thank you. That will help me make the login script able to handle both the acuconnect login and the interactive login.

    However, in this case, I have commented out the interactive part.

    The problem that I am experiencing is different than that. If the first acuconnect session is one with a machine specific access record, the thin client immediately terminates. The log file shows the start and immediate end of the session.

    If first acuconnect session matches the default wildcard record, it starts fine and the sessions matching machine specific access records do also.


    Example access records:
    Machine Client User Local User Password Umask
    * userguest 000
    WIN1 user1 000
    WIN2 user2 000
    D

    [Migrated content. Thread originally posted on 25 September 2007]

    I found the most common cause of problems when you set USE_UNIX_SHELL is the "interactive" stuff performed in user's login scripts (e.g. /home/bill/.bash_profile). Here's an example of how we've modified our login scripts to accommodate AcuConnect:-
    # a shell started by acurcl (with USE_UNIX_SHELL=1) will skip over this:
    if [ "$PS1" ]; then
        # shell is interactive, so put your interactive code here.
        # the following will loop endlessly if started via acurcl:
        while [ -z "fname" ]; do
            echo -n "What is your first name?  "
            read fname
        done
        echo "Hello $fname"
    fi
    # no more interactive code beyond here!
    Thank you. That will help me make the login script able to handle both the acuconnect login and the interactive login.

    However, in this case, I have commented out the interactive part.

    The problem that I am experiencing is different than that. If the first acuconnect session is one with a machine specific access record, the thin client immediately terminates. The log file shows the start and immediate end of the session.

    If first acuconnect session matches the default wildcard record, it starts fine and the sessions matching machine specific access records do also.


    Example access records:
    Machine Client User Local User Password Umask
    * userguest 000
    WIN1 user1 000
    WIN2 user2 000
    D

    [Migrated content. Thread originally posted on 25 September 2007]

    I found the most common cause of problems when you set USE_UNIX_SHELL is the "interactive" stuff performed in user's login scripts (e.g. /home/bill/.bash_profile). Here's an example of how we've modified our login scripts to accommodate AcuConnect:-
    # a shell started by acurcl (with USE_UNIX_SHELL=1) will skip over this:
    if [ "$PS1" ]; then
        # shell is interactive, so put your interactive code here.
        # the following will loop endlessly if started via acurcl:
        while [ -z "fname" ]; do
            echo -n "What is your first name?  "
            read fname
        done
        echo "Hello $fname"
    fi
    # no more interactive code beyond here!
    Thank you. That will help me make the login script able to handle both the acuconnect login and the interactive login.

    However, in this case, I have commented out the interactive part.

    The problem that I am experiencing is different than that. If the first acuconnect session is one with a machine specific access record, the thin client immediately terminates. The log file shows the start and immediate end of the session.

    If first acuconnect session matches the default wildcard record, it starts fine and the sessions matching machine specific access records do also.


    Example access records:
    Machine Client User Local User Password Umask
    * userguest 000
    WIN1 user1 000
    WIN2 user2 000
    D

    [Migrated content. Thread originally posted on 25 September 2007]

    I found the most common cause of problems when you set USE_UNIX_SHELL is the "interactive" stuff performed in user's login scripts (e.g. /home/bill/.bash_profile). Here's an example of how we've modified our login scripts to accommodate AcuConnect:-
    # a shell started by acurcl (with USE_UNIX_SHELL=1) will skip over this:
    if [ "$PS1" ]; then
        # shell is interactive, so put your interactive code here.
        # the following will loop endlessly if started via acurcl:
        while [ -z "fname" ]; do
            echo -n "What is your first name?  "
            read fname
        done
        echo "Hello $fname"
    fi
    # no more interactive code beyond here!
    I think I've seen this before and resolved it by putting the client user name in as well as the PC name. Acurcl seems to be better able to match name pairs like this, rather than just the PC name.

    To see what is going on, try tracing the acurcl process and watching the log file as you attempt to connect.

    Hope that helps a bit :)

    Ian
    D

    [Migrated content. Thread originally posted on 25 September 2007]

    I found the most common cause of problems when you set USE_UNIX_SHELL is the "interactive" stuff performed in user's login scripts (e.g. /home/bill/.bash_profile). Here's an example of how we've modified our login scripts to accommodate AcuConnect:-
    # a shell started by acurcl (with USE_UNIX_SHELL=1) will skip over this:
    if [ "$PS1" ]; then
        # shell is interactive, so put your interactive code here.
        # the following will loop endlessly if started via acurcl:
        while [ -z "fname" ]; do
            echo -n "What is your first name?  "
            read fname
        done
        echo "Hello $fname"
    fi
    # no more interactive code beyond here!
    I think I've seen this before and resolved it by putting the client user name in as well as the PC name. Acurcl seems to be better able to match name pairs like this, rather than just the PC name.

    To see what is going on, try tracing the acurcl process and watching the log file as you attempt to connect.

    Hope that helps a bit :)

    Ian
    D

    [Migrated content. Thread originally posted on 25 September 2007]

    I found the most common cause of problems when you set USE_UNIX_SHELL is the "interactive" stuff performed in user's login scripts (e.g. /home/bill/.bash_profile). Here's an example of how we've modified our login scripts to accommodate AcuConnect:-
    # a shell started by acurcl (with USE_UNIX_SHELL=1) will skip over this:
    if [ "$PS1" ]; then
        # shell is interactive, so put your interactive code here.
        # the following will loop endlessly if started via acurcl:
        while [ -z "fname" ]; do
            echo -n "What is your first name?  "
            read fname
        done
        echo "Hello $fname"
    fi
    # no more interactive code beyond here!
    I just added two more access records for two new workstations. I included the Machine Name and Client User name. It was working for a short period and now logs in and right back out. It does map to the correct user login name per the acurcl log. I then tried setting up an access record with just the Machine Name. It also maps to the correct user login name but logs right back out.

    If I remove the access record and let it match back to the wildcard access record, it works but points to the wrong user login.

    In the case of my first post, once one system was in (using wildcard access), the systems using Machine Name access records would work. In this case, there are already systems in using both wildcard access and Machine Name access.

    I'm at a total loss as to what I might be doing wrong here...
    D

    [Migrated content. Thread originally posted on 25 September 2007]

    I found the most common cause of problems when you set USE_UNIX_SHELL is the "interactive" stuff performed in user's login scripts (e.g. /home/bill/.bash_profile). Here's an example of how we've modified our login scripts to accommodate AcuConnect:-
    # a shell started by acurcl (with USE_UNIX_SHELL=1) will skip over this:
    if [ "$PS1" ]; then
        # shell is interactive, so put your interactive code here.
        # the following will loop endlessly if started via acurcl:
        while [ -z "fname" ]; do
            echo -n "What is your first name?  "
            read fname
        done
        echo "Hello $fname"
    fi
    # no more interactive code beyond here!
    I just added two more access records for two new workstations. I included the Machine Name and Client User name. It was working for a short period and now logs in and right back out. It does map to the correct user login name per the acurcl log. I then tried setting up an access record with just the Machine Name. It also maps to the correct user login name but logs right back out.

    If I remove the access record and let it match back to the wildcard access record, it works but points to the wrong user login.

    In the case of my first post, once one system was in (using wildcard access), the systems using Machine Name access records would work. In this case, there are already systems in using both wildcard access and Machine Name access.

    I'm at a total loss as to what I might be doing wrong here...
    D

    [Migrated content. Thread originally posted on 25 September 2007]

    I found the most common cause of problems when you set USE_UNIX_SHELL is the "interactive" stuff performed in user's login scripts (e.g. /home/bill/.bash_profile). Here's an example of how we've modified our login scripts to accommodate AcuConnect:-
    # a shell started by acurcl (with USE_UNIX_SHELL=1) will skip over this:
    if [ "$PS1" ]; then
        # shell is interactive, so put your interactive code here.
        # the following will loop endlessly if started via acurcl:
        while [ -z "fname" ]; do
            echo -n "What is your first name?  "
            read fname
        done
        echo "Hello $fname"
    fi
    # no more interactive code beyond here!
    It doesn't sound like you're doing anything wrong. I suggest you get in touch with Tech Support :( :(
    D

    [Migrated content. Thread originally posted on 25 September 2007]

    I found the most common cause of problems when you set USE_UNIX_SHELL is the "interactive" stuff performed in user's login scripts (e.g. /home/bill/.bash_profile). Here's an example of how we've modified our login scripts to accommodate AcuConnect:-
    # a shell started by acurcl (with USE_UNIX_SHELL=1) will skip over this:
    if [ "$PS1" ]; then
        # shell is interactive, so put your interactive code here.
        # the following will loop endlessly if started via acurcl:
        while [ -z "fname" ]; do
            echo -n "What is your first name?  "
            read fname
        done
        echo "Hello $fname"
    fi
    # no more interactive code beyond here!
    It doesn't sound like you're doing anything wrong. I suggest you get in touch with Tech Support :( :(
    D

    [Migrated content. Thread originally posted on 25 September 2007]

    I found the most common cause of problems when you set USE_UNIX_SHELL is the "interactive" stuff performed in user's login scripts (e.g. /home/bill/.bash_profile). Here's an example of how we've modified our login scripts to accommodate AcuConnect:-
    # a shell started by acurcl (with USE_UNIX_SHELL=1) will skip over this:
    if [ "$PS1" ]; then
        # shell is interactive, so put your interactive code here.
        # the following will loop endlessly if started via acurcl:
        while [ -z "fname" ]; do
            echo -n "What is your first name?  "
            read fname
        done
        echo "Hello $fname"
    fi
    # no more interactive code beyond here!
    It doesn't sound like you're doing anything wrong. I suggest you get in touch with Tech Support :( :(
    D

    [Migrated content. Thread originally posted on 25 September 2007]

    I found the most common cause of problems when you set USE_UNIX_SHELL is the "interactive" stuff performed in user's login scripts (e.g. /home/bill/.bash_profile). Here's an example of how we've modified our login scripts to accommodate AcuConnect:-
    # a shell started by acurcl (with USE_UNIX_SHELL=1) will skip over this:
    if [ "$PS1" ]; then
        # shell is interactive, so put your interactive code here.
        # the following will loop endlessly if started via acurcl:
        while [ -z "fname" ]; do
            echo -n "What is your first name?  "
            read fname
        done
        echo "Hello $fname"
    fi
    # no more interactive code beyond here!
    I think I've found the problem. In this case, it seems to have been a permissions problem caused by the user shell overriding the permissions set in the acurcl access record.

    Normal user shell permissions are more restrictive than the permissions required by our application. This doesn't totally explain the first instance of the problem but dealing with it explicitly in the user shell seems to have fixed it.

    Thank you, Blacky, for your insights and help. I did make use of your first suggestion in my implementation of the user shell scripts.
    D

    [Migrated content. Thread originally posted on 25 September 2007]

    I found the most common cause of problems when you set USE_UNIX_SHELL is the "interactive" stuff performed in user's login scripts (e.g. /home/bill/.bash_profile). Here's an example of how we've modified our login scripts to accommodate AcuConnect:-
    # a shell started by acurcl (with USE_UNIX_SHELL=1) will skip over this:
    if [ "$PS1" ]; then
        # shell is interactive, so put your interactive code here.
        # the following will loop endlessly if started via acurcl:
        while [ -z "fname" ]; do
            echo -n "What is your first name?  "
            read fname
        done
        echo "Hello $fname"
    fi
    # no more interactive code beyond here!
    I think I've found the problem. In this case, it seems to have been a permissions problem caused by the user shell overriding the permissions set in the acurcl access record.

    Normal user shell permissions are more restrictive than the permissions required by our application. This doesn't totally explain the first instance of the problem but dealing with it explicitly in the user shell seems to have fixed it.

    Thank you, Blacky, for your insights and help. I did make use of your first suggestion in my implementation of the user shell scripts.

    Recent badge winners

    Explore all badges
    Terms & ConditionsAccessibility statement