Category Archives: Windows

Samba 4 + Windows 10 time synchronization issues

Leave a reply

Where does ListeningThread -- Recvd 52 of 48/68 bytes come from?

If you follow the instructions for setting up Samba 4 AD DC for time synchronization, ntpd (coming out of Debian’s ntp package at some version 4.2.8) should just work.1

I came to this discovery after giving up and discarding my /etc/ntp.conf. Suddenly, after restarting ntpd and running w32tm /resync, things just worked. It’s not the software that’s broken — it’s me that was crazy.

The packet was now 110 bytes in Wireshark (68 of which was data). This was a stark improvement over seeing a 94 byte packet (52 of which was data). C:\temp\ntpDebug.log 2 no longer contained this:

ListeningThread -- Recvd 52 of 48/68 bytes

Hoozah! Now I wanted to figure out what was causing ntpd to send 52b packets, and not either 48b or 68b packets.

Turns out that my restrict statements had unexpected side effects. For instance, Samba wiki-recommended config tries to unrestrict localhost using restrict 127.0.0.1. 3

But I wanted to do the same for IPv6 localhost, so I did restrict ::1. This seems to have greatly confused ntpd.

The way out?

restrict -4 127.0.0.1
restrict -6 ::1

Second mistake was restrict 10.10.10.0 mask 255.255.255.0. It didn’t specify that mssntp should be enabled. For good measure I threw in -4:

restrict -4 10.10.10.0 mask 255.255.255.0 mssntp

Given that Samba config doesn’t recommend any special allowlisting for my internal IP range, I’ll just remove this line completely; the default restriction from the wiki should cover everything clients need to do anyway:

# Access control
# Default restriction: Allow clients only to query the time
restrict default kod nomodify notrap nopeer mssntp

Moral of the story? ntpd seems to be awfully sensitive to restrict statements. If w32time service complains or breaks in some way, be sure to remove the statements bit by bit, or make sure IPv4 and IPv6 statements don’t stomp over each other.

  1. Granted, I needed to modify the path to the socket to say /var/lib/samba/ntp_signd/ instead of /usr/local/samba/var/lib/ntp_signd/, but otherwise it just worked. ↩
  2. That file was created using w32tm /debug /enable /file:C:\temp\ntpDebug.log /size:102400 /entries:0-300 which I found somewhere online. ↩
  3. Apparently, passing no restrictions at all after the address simply means “unrestrict these peers”. ↩

Detecting location of Visual Studio 2017 and 2019

Leave a reply

A few years ago, I wanted to use Bazel to build an old project of mine using Visual Studio 2017 Community.

Thing is, I don’t install most of MSVS on my system partition, as it’s on a relatively tiny SSD. So, where do I (portably) find it? And how do I set BAZEL_VS (per their documentation) to the correct path?

As I’m much more comfortable writing Bash scripts than writing old DOS-style Batch scripts, and as I’m going to have msys64 (or at least msys32) on my machines, clearly the answer is to write the resulting launcher in Bash. There are downsides to this approach, but it’s doable.

Do you even need this for Bazel?

No. I just tried running bazel-2.0.0-windows-x86_64.exe with my project. It found MSVS2019 out of the box both in cmd.exe and in the MSYS64 shell.

Unfortunately, I have a genrule that depends on bash, which didn’t work in cmd.exe even if I specified BAZEL_SH (missing binary for basename). And when I didn’t pass BAZEL_SH while running under MSYS64, it had trouble finding SDL/SDL.h presumably because the aforementioned genrule didn’t work.

Autodetection of MSVS2019 works, just set PATH Windows envvar to include msys binaries, and set BAZEL_SH Windows envvar to the output of cygpath -w /usr/bin/bash or cygpath -w /bin/bash.

You may want this for non-Bazel uses.

Finding Microsoft Visual Studio 2017

Assuming Bazel 2.0.0 is installed in C:\bazel under the default filename from the release on Github, this does the trick:

#!/bin/bash
# Based on https://superuser.com/a/539680 + searching around registry.
# Finds MSVS2017.
# Slashes when invoking 'reg query' are replaced with dashes because MSYS2.
VSPATH="$(cygpath -u "$(reg query 'HKLM\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\SxS\VS7' -v 15.0 | tail -n+3 | head -n1  | awk '{for (i=3;i<=NF;i++) {printf "%s ",$i;};}' | sed 's/ *$//')")"

export BAZEL_SH="$(cygpath -w /usr/bin/bash)"
export BAZEL_VS="$VSPATH"

/c/bazel/bazel-2.0.0-windows-x86_64.exe $@

Finding Microsoft Visual Studio 2019

Unfortunately this is broken as of MSVS2019. See the explanation why that registry key is not used anymore.

The new situation is better: there’s a tool that does get installed in a well-known path: %ProgramFiles(x86)%/Microsoft Visual Studio/Installer/vswhere.exe.

The problem is merely that Bash doesn’t like parentheses in environment variable names, so ${ProgramFiles(x86)} won’t be acceptable. However, it was visible in env output! Other people have spotted the same thing, but as their writings talk about PROGRAMFILES(X86) in all caps, I’ve concluded that maybe it’s better to add the I flag to their sed-based solution.

#!/bin/bash
# Let's use VSWhere:
PROGRAMFILES_X86=$(env | sed -n s,'^PROGRAMFILES(X86)=',,pI) # because parens are not valid envvar names: http://mingw-users.1079350.n2.nabble.com/msysGit-bash-and-PROGRA$
VSWHERE=${PROGRAMFILES_X86}/Microsoft\ Visual\ Studio/Installer/vswhere.exe
VSWHERE="$(cygpath -u "${VSWHERE}")"

# Finding VC: https://github.com/microsoft/vswhere/wiki/Find-VC
VSPATH=$("${VSWHERE}" -latest -products '*' -requires Microsoft.VisualStudio.Component.VC.Tools.x86.x64 -property installationPath)

export BAZEL_SH="$(cygpath -w /usr/bin/bash)"
export BAZEL_VS="$VSPATH"

/c/bazel/bazel-2.0.0-windows-x86_64.exe $@

VSCode

The problem with using Bazel integration into VSCode is that it wants a path to Bazel. But Bazel wants to have BAZEL_VS set.

Maybe I could work around this by writing a tool in a compilable language, then have it pass on all CLI arguments to actual bazel.exe, while also setting BAZEL_VS. Or maybe Bazel supports some settings in .bazelrc. I didn’t care to check. Instead, I’ve used msys2_shell.cmd as the ‘shell’ for the integrated VSCode terminal. I’m used to manually running Bazel and I don’t care enough about interactive debugging. For now, I just don’t care enough to properly integrate Bazel into VSCode on Windows (though it would be neat).

Why even bother with Windows?

I need to trivially compare networking traffic between my project and a third-party program. The third-party program is written for Windows; it would likely work on other platforms under Wine, but I don’t care enough to explore whether I can make a third-party binary patcher for that program work under Wine.

My program still works on Linux, built whether with Bazel or using Makefiles; but the deprecated SDL 1.2 was recently broken on macOS, my program won’t work on macOS.

Getting this to work is also a nice exercise.

Samba AD issues are hard, hard, hard to fix

Leave a reply

So it looks like I did something wrong at some point while setting up a domain and Samba4 is now broken for me.

Of course this had to happen after I spent time migrating my local account to the domain account. (No, it did not go as smoothly as the sources might lead you to believe.)

So I am understandably reluctant to reprovision the machine and go through that process again, breaking who-knows-what-else by breaking the NTFS ACLs formed since.

So yeah, I’ll use this post as an outlet for complaints about this breakage:

Mar  1 00:42:17 commander samba[12250]: [2015/03/01 00:42:17.752020,  0] ../lib/util/util_runcmd.c:317(samba_runcmd_io_handler)
Mar  1 00:42:17 commander samba[12250]:   /usr/sbin/samba_dnsupdate: Traceback (most recent call last):
Mar  1 00:42:17 commander samba[12250]: [2015/03/01 00:42:17.753033,  0] ../lib/util/util_runcmd.c:317(samba_runcmd_io_handler)
Mar  1 00:42:17 commander samba[12250]:   /usr/sbin/samba_dnsupdate:   File "/usr/sbin/samba_dnsupdate", line 612, in <module>
Mar  1 00:42:17 commander samba[12250]: [2015/03/01 00:42:17.753757,  0] ../lib/util/util_runcmd.c:317(samba_runcmd_io_handler)
Mar  1 00:42:17 commander samba[12250]:   /usr/sbin/samba_dnsupdate:     get_credentials(lp)
Mar  1 00:42:17 commander samba[12250]: [2015/03/01 00:42:17.754374,  0] ../lib/util/util_runcmd.c:317(samba_runcmd_io_handler)
Mar  1 00:42:17 commander samba[12250]:   /usr/sbin/samba_dnsupdate:   File "/usr/sbin/samba_dnsupdate", line 118, in get_credentials
Mar  1 00:42:17 commander samba[12250]: [2015/03/01 00:42:17.755084,  0] ../lib/util/util_runcmd.c:317(samba_runcmd_io_handler)
Mar  1 00:42:17 commander samba[12250]:   /usr/sbin/samba_dnsupdate:     creds.set_machine_account(lp)
Mar  1 00:42:17 commander samba[12250]: [2015/03/01 00:42:17.755797,  0] ../lib/util/util_runcmd.c:317(samba_runcmd_io_handler)
Mar  1 00:42:17 commander samba[12250]:   /usr/sbin/samba_dnsupdate: RuntimeError: (-1073741275, 'NT_STATUS_NOT_FOUND')

…uh, so the machine account is missing? What? How did that happen? Is it really missing?

# samba-tool user create COMMANDER$
New Password: #DUMMYPASSWORDHERE#
Retype Password: #DUMMYPASSWORDHERE#
ERROR(ldb): Failed to add user 'COMMANDER$':  - samldb: Account name (sAMAccountName) 'COMMANDER$' already in use!

Let’s try this, found on Samba’s wiki:

samba-tool dbcheck --fix --reset-well-known-acls

Hurray, an error has been fixed! But everything is still horribly broken.

Oh look! There’s a DC diagnostics tool shipping in Windows:

C:\Users\ivucica>dcdiag /s:ds.badc0de.net /v

Directory Server Diagnosis

Performing initial setup:
   * Connecting to directory service on server ds.badc0de.net.
   Ldap search capability attribute search failed on server ds.badc0de.net,
   return value = 52

Thanks, Microsoft, that’s helpful.

So I fiddled a bit and ended up with this:

C:\Users\ivucica>dcdiag /s:commander

Directory Server Diagnosis

Performing initial setup:
   Ldap search capability attribute search failed on server commander, return
   value = 81

C:\Users\ivucica>dcdiag /s:commander.ds.MYDOMAIN

Directory Server Diagnosis

Performing initial setup:
   Ldap search capability attribute search failed on server
   commander.ds.MYDOMAIN, return value = 81

No, passing /v did not help identifying either error 52 nor 81. But that 81 is mildly googlable. Wait, it’s mentioning LDAP… Is it even running?

Oh wait, Microsoft has another diagnostics tool (of course it does)

C:\Users\ivucica>nltest /dsgetdc:ds.MYDOMAIN force /gc
Getting DC name failed: Status = 1355 0x54b ERROR_NO_SUCH_DOMAIN

Of course there is no such domain, why would there be, am I right? tcpdump revealed that UDP packets on 389 were being rejected (and nothing is listening there). And connections to localhost were failing. So let’s look at help for samba-tool dbcheck. Huh. Let’s try this:

samba-tool dbcheck --fix --reindex --scope=base

And breakage begone!

C:\Users\ivucica>nltest /dsgetdc:ds.MYDOMAIN /force /gc
           DC: \\commander.ds.MYDOMAIN
      Address: \\10.0.99.150
     Dom Guid: b066b58f-6fa9-42d6-a45a-ABCDEFABCDEF
     Dom Name: ds.MYDOMAIN
  Forest Name: ds.MYDOMAIN
 Dc Site Name: DO-AMS1
        Flags: PDC GC DS LDAP KDC TIMESERV GTIMESERV WRITABLE DNS_DC DNS_DOMAIN
DNS_FOREST
The command completed successfully

Or not?

C:\Users\ivucica>dcdiag /s:ds.badc0de.net /v

Directory Server Diagnosis

Performing initial setup:
   * Connecting to directory service on server ds.badc0de.net.
   Ldap search capability attribute search failed on server ds.badc0de.net,
   return value = 52

Back to 52. And samba_dnsupdate is still broken, and the workstation cannot administrate the DC. Because, “The server is not operational.” Thanks, Samba, and thanks, Windows, for your immensely useful error messages.

Very, very discouraging and even a bit disturbing.

Error when applying group policies on a Samba 4 AD member

3 Replies

Today I ran into the following issue:

C:\WINDOWS\system32>gpupdate /force
Updating policy...

Computer policy could not be updated successfully. The following errors were encountered:

The processing of Group Policy failed. Windows attempted to read the file 
\\YOUR.DOMAIN\sysvol\YOUR.DOMAIN\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\gpt.ini
from a domain controller and was not successful. Group Policy settings
may not be applied until this event is resolved. This issue may be transient and
could be caused by one or more of the following:
a) Name Resolution/Network Connectivity to the current domain controller.
b) File Replication Service Latency (a file created on another domain controller
 has not replicated to the current domain controller).
c) The Distributed File System (DFS) client has been disabled.
User Policy update has completed successfully.

To diagnose the failure, review the event log or run GPRESULT /H GPReport.html 
from the command line to access information about Group Policy results.

The solution is simple:

samba-tool ntacl sysvolreset

Found in a mailing list post.

A simple WiX template for games

Leave a reply

Over the last few days, I’ve got some comments and emails about my old, old post about WiX in which I promised to release a functional template.

Since that work with WiX was originally done for some games, and in the meantime I began working with OS X most of the time, it took “a while” for me to grab some time and remove company branding, create a sample project, and finally prepare and release the template for my own as well as other people’s use.

You can the template from its Bitbucket repository . Have fun!

Little tips on writing portable plugins (and rant on MSVC)

Leave a reply

Having written a smallish plugin for a cross-platform database program FileMaker using a template that included projects for Xcode and VC, here’s a few tips on what you should think about when you start writing a plugin that should work on multiple platforms.

  1. Work on the Windows version first. If you’re at home on non-Windows platforms, MSVC will surprise you in numerous ways with its oddities and weird, outdated support for C.
  2. Write as much code in C for portability.
  3. Write in C90. Microsoft Visual Studio will barf a lot at you otherwise.
  4. If you disregarded #3 and wrote the code in C99 (for example, you declared variables during the function body instead of on the top of the function), you’ll have to switch to C++ to avoid changes to your code.
  5. Don’t write smart code. For example, MSVC barfs at the following:

    typedef struct _IVRect
{
  int x, y, w, h;
} IVRect;

IVRect r = { .x = 5, .y = 6, .w = 7, .h = 8 };

// but the following is ok. just don't change the order of
// struct members. if you do -- woe upon you:
IVRect s = { 5, 6, 7, 8 };

    and it especially barfs at the following:

    // given int IVRectSurfaceSum(const int rectCount, Rect * r):
int surface = IVRectSurface(2, (IVRect[]) 
  {
    { .x = 5, .y = 6, .w = 7, .h = 8 },
    { .x = 1, .y = 2, .w = 3, .h = 4 } 
  });
  6. Use as many open source libraries available for majority of your platforms.
  7. …but always check what MSVC can swallow and what your target app uses. I have used version of libxml2 that depended on the newer zlib1.dll than has shipped with FileMaker. The only solution I found is — replacing FileMaker’s zlib1.dll. That’s nasty.
  8. Always write a small test C program that uses the same functions as your plugin. Port that to every platform first. On Windows, I couldn’t get stdout from my plugin once it ran under FileMaker. If I could’ve, I would’ve saved about a day of frustration why signing with xmlsec didn’t work. (xmlsec’s debug output wasn’t displayed anywhere, either).
  9. Get used to #ifdef _MSC_VER. Get really, really, really used to it.

    10. Since I’m not sure you could figure that out… I have a very low opinion about Visual C++. I did hear it produces nice, fast code. But that doesn’t change the fact that it’s terrible to use with low coverage of modern C. Actually, scratch that: nonexistent coverage of modern C.

    I mean, it’s so nasty that I’m wondering if I should have built a helper static library (or a DLL) which contained the C code using MinGW, and then used this helper library in the plugin itself.

    Visual C++ was — for me — slow, had little conformance with modern standards, and every time I had to copypaste something somewhere using GUI, a little part of me died. A slightly larger part if I had to overwrite something else, as was the case with zlib1.dll.

    I don’t know. Sure, it’s mostly familiarity-with-other-IDEs speaking out of me. Sure, tons and tons of people prefer and absolutely love Visual C++. Good for them.

    But, I apparently love modern language features far, far more. So, if you are like me, and if you are forced to build something with MSVC (an example might be — the SDK you’re writing the plugin with chose to use C++, hence the ABI is locked into MSVC), you really, really, really should constantly doublecheck if MSVC will eat up what you try to serve to it.

    Because if you used to work with Windows, and if you are nowadays mostly targeting another platform (or at least another compiler), and if you think you’re writing portable code — you may be in for a nasty surprise.

    Especially if you use third-party libraries!