Wolfgang Riedmann Blog

After the update to Windows 10 Build 1803 machines could not more connect to the Oracle server when the application was started from a network share or a mapped network drive.

These problems were caused by the fact that applications started from a SMB v1 share could not more connect to any network service (file based access was ok).

The server was a Debian Wheezy Linux machine with Samba 3.6. Samba 3.6 is the first Samba version that supports SMB v2 connections, but unfortunately they are disabled by default. To enable them, you must add the following line to the Samba configuration file /etc/samba/smb.conf:

max protocol = SMB2

Restart Samba and your Windows client, and the connection will be SMBv2.
You can check this opening a PowerShell with administrative (elevated) rights and the following command:

get-smbConnection

Applications that will not work from a SMBv1 share include: email programs, SSH Clients (putty), curl, database clients, and any type of program that opens some network connection.

In the upgrade of another customer server I had a very unusual issue: the server was using a Sernet Samba version, and the upgrade from Debian Squeeze to Debian Wheezy removed this Samba version. A new installation of the Debian version could not find any users anymore.
Strangely, the Sernet Samba version had their user database in /etc/samba, and the Debian Samba version in /var/lib/samba. Stopping Samba and copying over these database files fixed the issue.

Our most busy server sometimes showed long connection times after we changed the default protocol from http to https.

This server is running Apache 2.4.10 on Debian Wheezy, and the slow connection times manifested themselves after periods of higher than normal load, but far from being critical.

I have tried a lot of different things, like incrementing the number of Apache processes, limiting the number of concurrent outgoing mails (the server sends about 20.000 emails every day), and also adding more memory to the system – but nothing helped.

Unfortunately, http/2 is not available with this Apache version, and I don’t like to backport from a newer Debian version. The same is true for ALPN and NPN – both not available in the installed Apache version.

The solution was to enable OCSP stapling:

SSLUseStapling on
SSLStaplingCache shmcb:/tmp/stapling_cache(128000)

Now the maximum connection times are down to about 5 seconds in the most busy periods, instead of reaching 20 seconds and more. In times of normal load the connection times are below 0.1 seconds.

As test I can recommend the SSLLabs test by Qualys: https://www.ssllabs.com/ssltest/analyze.html

Microsoft supports SQL Server access from Linux and PHP 7, but unfortunately not with Debian 9 Stretch, but only for Debian 8 (and Ubuntu 15.10, Ubuntu 16.10, Ubuntu 6.04, RedHat 7 and MacOS).

See https://docs.microsoft.com/en-us/sql/connect/php/installation-tutorial-linux-mac

I have tried to use the PDO Sybase drivers (package php7.0-sybase), but was not able to connect.

Then I found the page https://github.com/Microsoft/msphpsql/releases and have done the following:

pecl install sqlsrv-5.1.1preview
pecl install pdo_sqlsrv-5.1.1preview

The build failed until I installed the package unixodbc-dev
apt-get install unixodbc-dev

To enable the both modules in Apache2, I have done also the following:
cd /etc/php/7.0/mods-available
cp pdo_dblib.ini pdo_sqlsrv.ini
cp pdo_dblib.ini sqlsrv.ini
changed the contents of the files to list the appropriate -so file (pdo_sqlsrv.so and sqlsrv.so),
cd /etc/php/7.0/apache2/conf.d
ln -s /etc/php/7.0/mods-available/sqlsrv.ini 20-sqlsrv.ini
ln -s /etc/php/7.0/mods-available/pdo_sqlsrv.ini 20-pdo_sqlsrv.ini
and restarted Apache2.

Now, my test function returned that the ODBC driver was missing.
I have downloaded then the Debian 8 version and installed the driver and the tools:
wget https://packages.microsoft.com/debian/8/prod/pool/main/m/msodbcsql/msodbcsql_13.1.9.1-1_amd64.deb
wget https://packages.microsoft.com/debian/8/prod/pool/main/m/mssql-tools/mssql-tools_14.0.7.0-1_amd64.deb
apt-get install unixodbc
dpkg -i msodbcsql_13.1.9.1-1_amd64.deb
dpkg -i mssql-tools_14.0.7.0-1_amd64.deb

After this, I was able to connect to the SQL server and run a select statement.

$conn = new PDO("sqlsrv:Server=$myserverName;Database=$myDB", $myUser, $myPass);

Installing Firebird on Debian (Jessie in my case) gave a problem: after installing and starting the server I was not able to connect to the database server:

Your user name and password are not defined. Ask your database administrator to set up a Firebird login.

using the sysdba password I entered in the installation dialog.

Unfortunately it seems the installation procedure has a bug, and does not accept the entered password, but attributes a random password. This random password can you find in the file

/etc/firebird/2.5/SYSDBA.password

The connect with this random password succeedes and you can change your password afterwards – but you must change it with both the Firebird administration tools and inside this file.

The password can be changed with the gsec tool:

gsec -user sysdba -password <password_from_SYSDBA.password>
modify sysdba -pw <your_new_password>
quit

And another speciality for Debian:

The isql tool is called isql-fb

Today, I had an interesting issue: Windows 10 (workgroup setting, local account) does not connect to the Samba netlogon share, even with the latest Samba version (4.2.3), it asks username and password.
Access to other shares works without any issue.
I had also checked the HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\AllowInsecureGuest setting – it does not change anything.
My temporary solution was to create a new share, identical to the netlogon share, with another name – I choosed netlogonw10. Calling the login script from this share works.

The same is true also for netlogon shares on Windows servers, if the machine is not in the Windows domain

Today, I had to change all IP addresses on a customers Samba network. (Really, the customer had two separate networks, and I have unified them to one).

After this, I had to add several Windows 7 PCs to the Samba domain, but the process failed, and the logs on the Samba server had no entries on this.

The error message was:

“The specified domain either does not exist or could not be contacted”

I had added the registry entries specified here:

wiki.samba.org/index.php/Registry_changes_for_NT4-style_domains

but nothing.

Finally, the nblookup tool downloadable from Microsofts website pointed me in the right direction: incorrect wins data!

The solution was simple:

/etc/init.d/samba stop
rm /var/lib/samba/wins.*
/etc/init.d/samba start

This recreated the correct wins database wins.tdb and the PC could be joined to the database.

After a power shortage, nobody could connect to the Samba shares of a Debian Linux server, and a look at “top” on the Linux server showed that the winbindd process used 100% cpu.

The solution was easy:

/etc/init.d/samba stop
/etc/init.d/winbind stop

a kill -9 <processnumber> to the running winbindd process.

Find and remove the gencache.tdb file (/var/lib/samba/gencache.tdb on my Debian server).

/etc/init.d/samba start
/etc/init.d/winbind start
/etc/init.d/samba stop
net rpc join -U administrator%<admin_password>
/etc/init.d/samba start

This fixed the problem.

Configuration: Domain master is a Windows SBS 2003, main file server a Debian Linux Lenny server using winbind as primary autentication mechanism.