You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficserver.apache.org by "Ethan Lai (JIRA)" <ji...@apache.org> on 2012/11/01 09:59:12 UTC

[jira] [Comment Edited] (TS-1551) ssl_multicert.config not reread with traffic_line -x

    [ https://issues.apache.org/jira/browse/TS-1551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13488559#comment-13488559 ] 

Ethan Lai edited comment on TS-1551 at 11/1/12 8:57 AM:
--------------------------------------------------------

James, my implementation does not reload SSLConfigParams, it just use it for SSLCertLookup instance build.

About the refcount, this could prevent critical section between ctx was returned from SSLCertLookup table but a ReloadInstance() called just before SSL_new() use this ctx. In this situation, SSL might refer a ctx already be freed. defaultContext() also should refer to a live ctx as well, and this refcount will be decrement just after calling SSL_new(). But since this SSLCert_FreerContinuation was delayed by at least 2 seconds, it might not be that necessary.
                
      was (Author: yzlai):
    James, my implementation does not reload SSLConfigParams, it just use it for SSLCertLookup instance build.

About the refcount, this could prevent critical section between ctx was returned from SSLCertLookup table but a ReloadInstance() called just before SSL_new() use it. In this situation, SSL might refer a ctx already be freed. defaultContext() also should refer to a live ctx as well, and this refcount will be decrement just after calling SSL_new(). But since this SSLCert_FreerContinuation was delayed by at least 2 seconds, it might not be that necessary.
                  
> ssl_multicert.config not reread with traffic_line -x
> ----------------------------------------------------
>
>                 Key: TS-1551
>                 URL: https://issues.apache.org/jira/browse/TS-1551
>             Project: Traffic Server
>          Issue Type: Bug
>          Components: Configuration, SSL
>    Affects Versions: 3.2.0
>         Environment: RHEL 6
>            Reporter: Ethan Lai
>            Assignee: James Peach
>            Priority: Minor
>         Attachments: ssl_multicert_reload.patch, ssl_multicert_reload.patch-3.2.0
>
>
> Found that "ssl_multicert.config" is marked as modified, but not reread while running traffic_line -x (Reread Config Files).
> Just wondering is this expected behavior or not?
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> [Oct 26 09:59:45.018] Manager {0x7f3c6723d7e0} NOTE: [LocalManager::startProxy] Launching ts process
> [Oct 26 09:59:45.025] Manager {0x7f3c6723d7e0} NOTE: [LocalManager::pollMgmtProcessServer] New process connecting fd '12'
> [Oct 26 09:59:45.025] Manager {0x7f3c6723d7e0} NOTE: [Alarms::signalAlarm] Server Process born
> [Oct 26 09:59:46.066] Server {0x2b500a320680} DEBUG: (ssl) ssl_multicert.config: /usr/local/etc/trafficserver/ssl_multicert.config
> [Oct 26 09:59:46.094] Server {0x2b500a320680} DEBUG: (ssl) mapping 'j1.free888.cloudns.biz' to certificate /usr/local/etc/ats-cert/j1.free888.cloudns.biz-v2.pem
> [Oct 26 09:59:46.096] Server {0x2b500a320680} NOTE: logging initialized[15], logging_mode = 3
> [Oct 26 09:59:46.126] Server {0x2b500a320680} NOTE: traffic server running
> $ sed -i 's/j1.free888.cloudns.biz-v2/j1.free888.cloudns.biz-v3/'  /usr/local/etc/trafficserver/ssl_multicert.config
> $ `trafflic_line -x`
> [Oct 26 09:59:59.954] Manager {0x7f3c5ffff700} DEBUG: (rollback) [Rollback::internalUpdate] Moving ssl_multicert.config from version 43 to version 44
> [Oct 26 09:59:59.970] Manager {0x7f3c5ffff700} NOTE: [fileUpdated] ssl_multicert.config file has been modified
> [Oct 26 09:59:59.970] Manager {0x7f3c5ffff700} NOTE: User has changed config file ssl_multicert.config
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> No "DEBUG: (ssl) mapping 'j1.free888.cloudns.biz' to certificate /usr/local/etc/ats-cert/j1.free888.cloudns.biz-v3.pem" message found.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira