none
SQL Server 2017 for Linux not listening for connections when the IP address is explicitly set

    Question

  • I am using SQL Server 2017 for Linux running on Debian 9 (stretch). Which, by the way, is really annoying that it isn't one of your supported platforms while Ubuntu is. In my opinion (and preference) Debian is a much better distro for servers. I can't be alone in this and I'm really surprised that you would support Ubuntu but not Debian. Especially considering if you supported Debian you would likely also support Ubuntu at the same time.

    To get it to work I downgraded my openssl package (which really feels like a bad idea but so be it) because the SQL Server 2017 packages have a dependency on openssl <= 1.1.0 and the Debian 9 repositories currently install version 1.1.0f-3+deb9u2 which isn't recognized as being compatible. I used the official backports repo to downgrade openssl to version 1.0.2l-1~bpo8+1 (It would also be handy if your package had a dependency on the sudo package because that isn't installed by default and is needed during the setup.)

    The openssl library doesn't appear to be causing any issue because I have successfully used encrypted connections to my server. The problem started when I tried to bind SQL Server to a specific IP address by using the command:

    mssql-conf set network.ipaddress XXX.XXX.XXX.XXX

    This is a physical server (dedicated host in a DC) that has 2 NIC and 4 IP addresses. After changing the setting the server will start but does not actually start listening on any ports. When this option was not set I could see the sqlserver process listening on 0.0.0.0:1433 using netstat -l  and I could connect just fine. But now it doesn't seem to be listening on anything which means I cannot connect to the server, of course. I can still see the processes running in ps. I have also tried explicitly setting the listening port to the default SQL Server port but the same behavior persists. I was previously connecting using the same IP and port that I have now set as the only IP so it isn't a routing or firewall issue.

    This is my configuration file. Everything worked before and I didn't change anything except network.ipaddress and network.tcpport.

    [sqlagent]
    enabled = true
    
    [EULA]
    accepteula = Y
    
    [network]
    forceencryption = 1
    ipaddress = AAA.BBB.C.DDD
    tlscert = /var/opt/mssql/secrets/mssql.pem
    tlskey = /var/opt/mssql/secrets/mssql.key
    tlsprotocols = 1.2
    tcpport = 1433

    SQL Server doesn't appear to be creating any log files at all. At least I don't see any that were updated today when I started the server. I checked messages, kernlog, and syslog. The only seemingly related entry is in syslog which is:

    Jul 13 01:26:17 discordia systemd[1]: Started Microsoft SQL Server Database Engine.

    That seems to indicate everything is fine.

    Am I missing something or is this a known issue?


    • Edited by MikeD314 Friday, July 13, 2018 7:00 AM added details to show the IP routing and ports are open
    Friday, July 13, 2018 5:48 AM

All replies

  • Hi Mike,

    As you know, mssql-conf is a configuration script that installs with SQL Server 2017 for Red Hat Enterprise Linux, SUSE Linux Enterprise server, and Ubuntu. Currently, Microsoft does not support Debian officially.

    For SQL Server on Debain, you can have a check:

    Installing Microsoft Sql Server on Debian Linux

    And your mssql.conf file looks like not complete. Please refer to following example:

    [EULA]
    accepteula = Y
    
    [coredump]
    captureminiandfull = true
    coredumptype = full
    
    [filelocation]
    defaultbackupdir = /var/opt/mssql/data/
    defaultdatadir = /var/opt/mssql/data/
    defaultdumpdir = /var/opt/mssql/data/
    defaultlogdir = /var/opt/mssql/data/
    
    [hadr]
    hadrenabled = 0
    
    [language]
    lcid = 1033
    
    [memory]
    memorylimitmb = 4096
    
    [network]
    forceencryption = 0
    ipaddress = 10.192.0.0
    kerberoskeytabfile = /var/opt/mssql/secrets/mssql.keytab
    tcpport = 1401
    tlscert = /etc/ssl/certs/mssql.pem
    tlsciphers = ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA
    tlskey = /etc/ssl/private/mssql.key
    tlsprotocols = 1.2,1.1,1.0
    
    [sqlagent]
    databasemailprofile = default
    errorlogfile = /var/opt/mssql/log/sqlagentlog.log
    errorlogginglevel = 7
    
    [telemetry]
    customerfeedback = true
    userrequestedlocalauditdirectory = /tmp/audit
    
    [traceflag]
    traceflag0 = 1204
    traceflag1 = 2345
    traceflag = 3456

    Remember to restart your SQL Server before the changes are applied.

    Regards,

    Pirlo Zhang 


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.


    Monday, July 16, 2018 8:16 AM