none
Submit Job via .NET API from Web site RRS feed

  • Question

  • Hi!

    I'm developing ASP.NET Web site for HPC Job submission. I have HPC Pack 2008 R2 on Windows Server 2008 R2 Enterprise SP1. The site is hosted on head node.

    The site has following web.config:

    <configuration>

           <system.web>

                 <trust level="Full" originUrl=""/>

                 <sessionState mode="InProc" timeout="1440" useHostingIdentity="false">

                 </sessionState>

                 <identity impersonate="true"/>

                 <compilation debug="true" maxBatchSize="2000000" maxBatchGeneratedFileSize="2000000" targetFramework="4.0">

                        <assemblies>

                               <add assembly="Microsoft.ReportViewer.WebForms, Version=9.0.0.0, Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A"/>

                               <add assembly="Microsoft.ReportViewer.Common, Version=9.0.0.0, Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A"/>

                               <add assembly="System.Design, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A"/>

                               <add assembly="System.Web.Extensions.Design, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>

                               <add assembly="System.Windows.Forms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/></assemblies>

                        <buildProviders>

                               <add extension=".rdlc" type="Microsoft.Reporting.RdlBuildProvider, Microsoft.ReportViewer.Common, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>

                        </buildProviders>

                 </compilation>

                 <authentication mode="Windows">

                 </authentication>

                 <customErrors mode="Off"/>

                 <pages validateRequest="true" controlRenderingCompatibilityVersion="3.5" clientIDMode="AutoID">

                 </pages>

                 <httpHandlers>

                        <add path="Reserved.ReportViewerWebControl.axd" verb="*" type="Microsoft.Reporting.WebForms.HttpHandler, Microsoft.ReportViewer.WebForms, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" validate="false"/>

                 </httpHandlers>

                 <httpRuntime maxRequestLength="2097151" executionTimeout="10675199"/>

                 <globalization culture="en-US" fileEncoding="windows-1251" requestEncoding="windows-1251" responseEncoding="windows-1251" responseHeaderEncoding="windows-1251" uiCulture="ru-RU"/>

                 <roleManager enabled="true"/>

           </system.web>

           <system.webServer>

                 <validation validateIntegratedModeConfiguration="false"/>

                 <security>

                        <requestFiltering>

                               <requestLimits maxAllowedContentLength="2000000000"/>

                        </requestFiltering>

                        <authorization>

                               <remove users="*" roles="" verbs=""/>

                               <add accessType="Allow" users="*"/>

                        </authorization>

                 </security>

                 <defaultDocument>

                        <files>

                               <clear/>

                               <add value="default.aspx"/>

                               <add value="Default.htm"/>

                               <add value="Default.asp"/>

                               <add value="index.htm"/>

                               <add value="index.html"/>

                               <add value="iisstart.htm"/>

                        </files>

                 </defaultDocument>

           </system.webServer>

    </configuration>

    I have following strange troubles with SubmitJob API function:

    1. If Application pool account is Network service (or any other built-in account, or any account with domain user permissions) SubmitJob(job, null, null) causes CPU 100% load by w3wp.exe and nothing happens.
    2. If Application pool account is domain and cluster admin account there are variations:
    • If logged in user is the same account as app pool account, all works fine.
    • If ASP.NET Impersonation turned off all works fine but this is bad solution because I need actual users being impersonated.
    • If logged in user is any other account exception is thrown:

    Description: The application attempted to perform an operation not allowed by the security policy. To grant this application the required permission please contact your system administrator or change the application's trust level in the configuration file.

    Exception Details: System.Security.SecurityException: Requested registry access is not allowed.

    I also tried to switch between 2.5 and 4.0 Framework but no success.

    All domain users have user permissions to HPC and can submit jobs via common job manager.

    Here is code sample which I used to test solution:

    protected void wzAddJob_FinishButtonClick(object sender, WizardNavigationEventArgs e)

            {

                _SendJobToCluster();

                _ClearSession();

                HttpResponse response = this.Response;

                response.Redirect("~/Task/ShowTasks.aspx");

            }

    private void _SendJobToCluster()

            {

                using (IScheduler scheduler = new Scheduler())

                {

                    scheduler.Connect("HNODEDC");

                    ISchedulerJob job = scheduler.CreateJob();

                    job.Name = "HPCSchedulerBasics Job";

                    job.UnitType = JobUnitType.Core;

                    job.AutoCalculateMin = false;

                    job.AutoCalculateMax = false;

                    job.MinimumNumberOfCores = 1;

                    job.MaximumNumberOfCores = 1;

                    job.SetJobTemplate("Ivan_Users");

                    ISchedulerTask task = job.CreateTask();

                    task.Name = "Hello World";

                    task.CommandLine = "echo Hello World";

                    job.AddTask(task);

                    scheduler.SubmitJob(job, null, null);

                    scheduler.Close();

                }

            }

    Does anyone have any suggestions how to deal with the problem?

    Thanks!

     


    Thursday, June 23, 2011 3:19 PM

Answers

All replies

  • Hi,

    When you are calling scheduler.SubmitJob(job,null, null) while running as impersonated user, are the credentials previously cached for this user?

    Thanks,
    Łukasz

    Monday, July 25, 2011 4:21 PM
  • Hi,

    When you are calling scheduler.SubmitJob(job,null, null) while running as impersonated user, are the credentials previously cached for this user?

    Thanks,
    Łukasz

    Hi!

    The credentials are not cached for any user.

    Wednesday, July 27, 2011 5:50 AM
  • Hi,

    In order to be able to call SubmitJob() with null passed for username and password you need to have these credentials cached earlier. Otherwise by default SubmitJob will attempt to show the console password prompt, which is not possible for your case, so it is looping infinitely (case 1 with 100% CPU load).

    There are several ways of caching credentials:

    http://technet.microsoft.com/en-us/library/microsoft.hpc.scheduler.ischeduler.setcachedcredentials(VS.85).aspx

    http://technet.microsoft.com/en-us/library/cc947669(WS.10).aspx

    http://technet.microsoft.com/en-us/library/cc972805(WS.10).aspx

    Thanks,
    Łukasz

    • Marked as answer by Ivan Bilokon Wednesday, August 3, 2011 9:57 AM
    Wednesday, July 27, 2011 3:29 PM
  • Hi,

    In order to be able to call SubmitJob() with null passed for username and password you need to have these credentials cached earlier. Otherwise by default SubmitJob will attempt to show the console password prompt, which is not possible for your case, so it is looping infinitely (case 1 with 100% CPU load).

    There are several ways of caching credentials:

    http://technet.microsoft.com/en-us/library/microsoft.hpc.scheduler.ischeduler.setcachedcredentials(VS.85).aspx

    http://technet.microsoft.com/en-us/library/cc947669(WS.10).aspx

    http://technet.microsoft.com/en-us/library/cc972805(WS.10).aspx

    Thanks,
    Łukasz

    Thank you for reply!

    I've cached credentials via cluscfg running under test user account. I set up ASP.NET Impersonation for the site. App pool is running under NetworkService account. But when I log in the site under the test user account SubmitJob method causes the same problem.

    Thursday, July 28, 2011 3:05 PM
  • Just to confirm - you are seeing the same problem with w3wp.exe eating the CPU? When this is happening could you check one thing? Is there a new job in configuring state created? Is your test user account the owner of this job?

    Thanks,
    Łukasz

    Thursday, July 28, 2011 5:53 PM
  • Just to confirm - you are seeing the same problem with w3wp.exe eating the CPU? When this is happening could you check one thing? Is there a new job in configuring state created? Is your test user account the owner of this job?

    Thanks,
    Łukasz

    Yes, I'm seeing the same problem. w3wp.exe eats CPU, the program hangs on  SubmitJob(job, null, null), the new job created is in configuring state and the test account is the owner of the job.
    Friday, July 29, 2011 10:03 AM
  • This still looks like a symptom of SubmitJob(job, null, null) not being able to access cached credentials. Could you try to test if using scheduler.SetCachedCredentials() in your code or simply supplying not 'null' parameters to SubmitJob() will help?

    I also recommend installing latest Service Pack as there were some improvements in how cached credentials are being handled by the server.

    Thanks,
    Łukasz

    Friday, July 29, 2011 3:43 PM
  • This still looks like a symptom of SubmitJob(job, null, null) not being able to access cached credentials. Could you try to test if using scheduler.SetCachedCredentials() in your code or simply supplying not 'null' parameters to SubmitJob() will help?

    I also recommend installing latest Service Pack as there were some improvements in how cached credentials are being handled by the server.

    Thanks,
    Łukasz

    Thank you for reply!

    I tried to call scheduler.SetCachedCredentials(User.Identity.Name, "thepassword") just before SubmitJob() and received System.UnauthorizedAccessException "Access to the registry key 'HKEY_CURRENT_USER\SOFTWARE\Microsoft\HPC\CachedCredentials\hnodedc' is denied." But calling SubmitJob() with username and password seems to be working.

    Sunday, July 31, 2011 6:00 PM
  • Does it solve your problem?

    I am not sure if you have a service pack installed, but I believe, that after installing latest patches (Sp2) you will not get the excpetion you've mentioned. Also to get an exception instead of password prompt inifinite loop you can use IScheduler.SetInterfaceMode() method called with the following parameters: SetInterfaceMode(false, new IntPtr(-1));. For more information take a look at: http://msdn.microsoft.com/en-us/library/microsoft.hpc.scheduler.ischeduler.setinterfacemode(v=VS.85).aspx

    Regards,
    Łukasz

    • Marked as answer by Ivan Bilokon Wednesday, August 3, 2011 9:57 AM
    Monday, August 1, 2011 8:34 PM
  • Does it solve your problem?

    I am not sure if you have a service pack installed, but I believe, that after installing latest patches (Sp2) you will not get the excpetion you've mentioned. Also to get an exception instead of password prompt inifinite loop you can use IScheduler.SetInterfaceMode() method called with the following parameters: SetInterfaceMode(false, new IntPtr(-1));. For more information take a look at: http://msdn.microsoft.com/en-us/library/microsoft.hpc.scheduler.ischeduler.setinterfacemode(v=VS.85).aspx

    Regards,
    Łukasz

    Thank you!

    The original idea was to allow users to submit jobs using only default Windows Authentication without providing any additional custom authentication information. But the API forces me to provide actual passwords which I cannot get in case of Windows Authentication only. So the problem is not completely solved. But thanks to your explanation I can make some workarounds now. Sp2 is not installed now but I''m going to install it soon.

    I also have few last questions:

    1. Is there a way to allow administrator to set cached credentials for any user? For now I was able to set cached credentials from the user context only.

    2. Why users are able to submit job via common job manager without any cached credentials? Does the job manager use different object model?

    Tuesday, August 2, 2011 10:54 AM
  • #1 Caching credentials for user1 has to be done from the user1 context, so user1 will be able to use them. If you already know user1 password to cache, you can quickly execute hpccred command as this user via Windows runas command.

    If you will cache user1 password while running as user2, this cached password will be available only to user2 for case when he wants to start new job with 'RunAs' option. In such case user2 will be the owner of the job, but user1 will be the RunAs user - the account used to start task processes with.

    #2 There is multiple reasons why we require users to provide or cache their credentials on job submission. One of them is a limitation of Kerberos ticket lifetime. Windows HPC system is operating with the assumption, that your job may stay in the queue for while. In such case additional logon maybe required at job startup and so the user password (or softcard certificate - SP2) is stored on the server.

    Job manager is no different than other interfaces. If you don't have your credentials cached it will prompt you to provide your password at first job submission. You can try that by first selecting menu option Options -> Clear Cached Job Credentials and then trying to submit new job.

    Regards,
    Łukasz

    Tuesday, August 2, 2011 4:46 PM
  • #1 Caching credentials for user1 has to be done from the user1 context, so user1 will be able to use them. If you already know user1 password to cache, you can quickly execute hpccred command as this user via Windows runas command.

    If you will cache user1 password while running as user2, this cached password will be available only to user2 for case when he wants to start new job with 'RunAs' option. In such case user2 will be the owner of the job, but user1 will be the RunAs user - the account used to start task processes with.

    #2 There is multiple reasons why we require users to provide or cache their credentials on job submission. One of them is a limitation of Kerberos ticket lifetime. Windows HPC system is operating with the assumption, that your job may stay in the queue for while. In such case additional logon maybe required at job startup and so the user password (or softcard certificate - SP2) is stored on the server.

    Job manager is no different than other interfaces. If you don't have your credentials cached it will prompt you to provide your password at first job submission. You can try that by first selecting menu option Options -> Clear Cached Job Credentials and then trying to submit new job.

    Regards,
    Łukasz

    Thank you very much!

    Now it is completely clear for me.

    Wednesday, August 3, 2011 9:56 AM