If you’ve used the dm0082 package in Stata, you may have experienced the following error when using commands such as stnd_compname:

No pattern file found in ~/ado/plus/p/

This error indicates that your installation of the dm0082 package is missing several important ancillary files. The message above is from a Linux system, but you should see a similar message on Windows or macOS.

Installing the Ancillary Files

The ancillary files for dm0082 are not automatically placed in the correct location when they are installed. Instead, they are copied to your current working directory. The following pattern files will need to be moved from your current working directory to the folder referenced in the error message above:

P10_namecomp_patterns.csv
P21_spchar_namespecialcases.csv
P22_spchar_remove.csv
P23_spchar_rplcwithspace.csv
P30_std_entity.csv
P40_std_commonwrd_name.csv
P50_std_commonwrd_all.csv
P60_std_numbers.csv
P70_std_nesw.csv
P81_std_smallwords_all.csv
P82_std_smallwords_address.csv
P90_entity_patterns.csv
P110_std_streettypes.csv
P120_pobox_patterns.csv
P131_std_secondaryadd.csv
P132_secondaryadd_patterns.csv

On Linux, the proper destination for these files will likely be ~/ado/plus/p/. If you are on Windows, it will likely be c:\ado\plus\p\.

You should also make sure that the name of each pattern file starts with a capital “P” rather than a lowercase “p”. The filenames may change to all lowercase when the ancillary files are downloaded. If that happens to you and you’re running Linux, you can use the rename command as described in this Ask Ubuntu post to quickly fix all the filenames at once.

Bonus Section: Finding the PLUS Directory in Stata

The ancillary files need to go in the proper subfolder of your PLUS directory. If you want to confirm whether the folder referenced in the error message is correct, you can find Stata’s PLUS directory by running the sysdir command:

. sysdir
   STATA: /usr/local/stata17/
    BASE: /usr/local/stata17/ado/base/
    SITE: /usr/local/ado/
    PLUS: ~/ado/plus/
PERSONAL: ~/ado/personal/
OLDPLACE: ~/ado/

From the Stata FAQ:

PLUS is where Stata installs ado-files from the SJ and STB and ado-files that you have downloaded from the Internet through the help system or with the net command.

References

• Fuzzy match in Stata | Kai Chen

SELinux has a well-earned reputation for being hard to use. It’s infamous for causing strange, illogical faults that can’t be fixed via normal troubleshooting routines, and, as a consequence, many guides and blog posts recommend disabling it outright. However, SELinux is a great way to secure and harden Linux systems, and with a few simple steps it’s possible to fix most common problems you might encounter while using it.

Examples of Common Issues

Let’s start by looking at a few issues I’ve had in the past that turned out to be caused by SELinux:

1. A user could no longer log in with an SSH key after their home directory was restored from a backup. Their authorized_keys file was configured correctly but was being ignored by SSH.
2. A service wouldn’t start after replacing its config file with a modified version that had been uploaded via SFTP. The service complained about the config file being inaccessible even though its permissions were set correctly.
3. Postfix couldn’t communicate with OpenDKIM when the latter was set to use a UNIX socket instead of a TCP/IP socket. The Postfix user was in the correct security group and the socket was configured correctly.

Without a general understanding of how SELinux works, you might guess that the issues above were caused by bad file permissions. That’s why it’s important to understand SELinux and to identify it as a possible culprit as early as possible in the troubleshooting process.

What is SELinux, Exactly?

At its core, SELinux is a set of rules that tell applications what they can and can’t do. SELinux is separate from the regular Linux file permissions model and is therefore able to protect against issues like misconfigured permissions or privilege escalation exploits. In order for an operation to succeed on an SELinux-enabled system, it must be permitted by file permissions as well as by the active SELinux policy.

Regular file permissions are a form of discretionary access control, or DAC. On the other hand, SELinux is a form of mandatory access control, or MAC. With DAC, a user or service can do anything they have permission to do, even if it’s something undesirable or dangerous. With MAC, malicious or dangerous actions can be stopped, even if a DAC policy would otherwise permit them to happen.

Here’s an example of why you’d want to keep SELinux enabled. Normally, Apache shouldn’t be able to read /etc/shadow, and the default file permissions prevent that from happening. However, if those permissions were misconfigured and Apache was configured to serve files from /etc, it would be possible for anyone with a web browser to download /etc/shadow. A properly configured SELinux policy would override both misconfigurations and prevent Apache from serving sensitive system files from /etc.

Putting Things in Context

Extra protection is great, but what happens when SELinux interferes when it shouldn’t? If SELinux is interfering with something “normal” that should otherwise work, chances are you have one simple problem: incorrect file security contexts. Security contexts are how SELinux categorizes files and decides which applications can access them. By default, security contexts are applied to files based on their location. For example, files in home directories get different security contexts from files in /etc or /tmp.

You can inspect a file’s security context with ls -Z, but you’re probably better off using restorecon to reset contexts to their default values if you suspect a problem. To save time, you can run restorecon -rv /path/to/directory to recursively reset the security contexts for an entire directory. If things are bad enough, you can relabel your entire filesystem by running touch /.autorelabel and then rebooting.

The restorecon command was the solution to problems #1 and #2 from the list at the beginning of this post. Incorrect security contexts can be applied when files are restored from a backup or copied from a nonstandard location.

Adjusting the Policy

In most mainstream Linux distributions, the default SELinux policy is carefully crafted by a group of upstream maintainers. Creating a perfect one-size-fits-all policy is impossible, so the maintainers provide built-in policy exceptions in the form of SELinux booleans. SELinux booleans can be easily enabled or disabled to cover common use cases where the default SELinux policy falls short. If you have an SELinux problem that can’t be fixed by restoring default file security contexts, you should check to see if an available SELinux boolean covers your use case.

You can use getsebool -a to retrieve a list of available booleans on your system and then use setsebool to enable or disable them. Alternatively, you can use the semanage tool to see more detailed information about available booleans. Examples of SELinux booleans include:

• use_nfs_home_dirs: Support NFS home directories.
• httpd_can_network_connect: Allow HTTPD scripts and modules to connect to the network.
• ftpd_full_access: Allow full filesystem access over FTP.

Rewriting the Policy

If fixing security contexts and enabling booleans hasn’t worked, ask yourself if you’re doing something abnormal. “Abnormal” in this context might include running a service on a nonstandard port, serving web files from an unconventional location, or moving config files out of their default directory. If you are, there’s a good chance your system’s default SELinux policy won’t cover your use case.

Before you proceed, you should think hard about what benefit you’re getting from running a nonstandard configuration. Standards exist for good reasons: troubleshooting is easier, malicious activity is simpler to detect, and applications can be configured to behave more predictably. With that said, there’s plenty of vendor software out there that relies on an “abnormal” configuration to work properly.

If you’ve evaluated your configuration and decided to proceed, you have two options. First, you may have discovered a bug in your platform’s SELinux policy, which means you should submit a bug report so that the policy can be fixed upstream. This is the course I ended up pursuing for the OpenDKIM issue mentioned above, and Red Hat updated the upstream policy after a few months.

Alternatively, you can write and compile a custom SELinux policy module. This is not as difficult as it sounds, as audit2allow can generate SELinux modules directly from audit log entries. A brief description of how to make use of the audit log is below, but a full explanation is beyond the scope of this post.

The Audit Log

By default, SELinux violations are logged to the audit log at /var/log/audit/audit.log. The best way to troubleshoot potential SELinux issues is to consult the audit log, but the default log format is not particularly user-friendly and raw entries are not always easy to understand. Instead of reading the audit log file directly, you can search the log with the ausearch tool or generate comprehensive, human-readable reports from it with the sealert tool. A full description of how to use those programs is provided by the documents in the “Read More” section at the bottom of this post.

Wrapping Up

SELinux has been around for a long time, and many mainstream Linux distributions now ship with robust SELinux policies that cover a range of use cases. Additionally, configuration management tools like Puppet can automatically set SELinux contexts for you and help you avoid inadvertently mislabeling files.

That said, the default SELinux policy can’t possibly cover all possible use cases, so you may still need to enable SELinux booleans or compile custom policy modules to make SELinux work for you. In any case, you should avoid disabling it outright, especially if you’re running a derivative of Fedora such as RHEL or CentOS where SELinux is intended to be the primary form of mandatory access control.

Read More

• What is SELinux? – Red Hat
• HowTos/SELinux – CentOS Wiki
• Getting started with SELinux :: Fedora Docs
• Troubleshooting SELinux :: Fedora Docs
• Basic SELinux Troubleshooting in CLI – Red Hat Customer Portal
• Using SELinux – Red Hat Enterprise Linux 8 | Red Hat Customer Portal

The banner image for this post was created by The Worlds Beyond.

Bitdefender Antivirus — the free edition, at least — appears to be interfering with Remote Desktop Protocol (RDP) connections on Windows. Affected users may receive the following error when they try to log on to a remote PC or server with Network Level Authentication (NLA) enabled:

An authentication error has occurred.

The Local Security Authority cannot be contacted.

This could be due to an expired password.

While an expired password or a server-side misconfiguration can cause this error, it may also indicate a client-side issue. In this case, the error appears to be caused by Bitdefender Antivirus replacing the remote computer’s certificate in order to inspect encrypted RDP traffic. This process breaks Network Level Authentication and causes the connection to fail.

One workaround is to add file-level exclusions in Bitdefender for both the 64-bit and 32-bit versions of the Windows RDP client:

• C:\Windows\system32\mstsc.exe
• C:\Windows\syswow64\mstsc.exe

This is not an ideal solution, but the free version of Bitdefender Antivirus has a limited control panel and does not provide alternative workarounds.

References

• Bitdefender Antivirus Free Edition breaking RDP : BitDefender
• Remote Desktop Connection Issue [SOLVED] – Microsoft Community
• Bitdefender Antivirus Free – remote Desktop block — The Bitdefender Expert Community
• AWS ec2 windows login error saying An authentication error has occured. The local security authority cannot be contacted – Stack Overflow

On Windows and macOS, Stata can be configured to check for updates automatically with the set update_query command. However, there are a few drawbacks to this approach.

For one, this feature isn’t present on the Linux version of Stata. For two, this command doesn’t actually update Stata — it just enables update notifications. Stata will still need to be manually updated by someone with the permission to do so.

If you’re running Stata on a standalone Linux server or an HPC cluster, you may be interested in having Stata update itself without any user interaction. This is especially useful if Stata users do not have permission to update the software themselves, as is often the case on shared Linux systems.

We can enable true automatic updates with a cron job and a Stata batch mode hack:

0 0 * * 0 echo 'update all' | /usr/local/stata16/stata > /dev/null

Adding this line to root’s crontab will cause the update all command to be run every Sunday at 12am. Standard output is piped to /dev/null to prevent cron from sending unnecessary emails.

As always, think carefully before enabling automatic updates for mission-critical pieces of software. However, this approach can save time over updating Stata manually.

Zoom’s meteoric rise to the top of the video conferencing market makes sense when you consider that their platform is, in fact, fairly good. So far, Zoom has managed to avoid many of the pain points that plague other video conferencing solutions:

• No account is required to join a call, and calls can be joined from any platform (even from Android, iOS, and Linux).
• Call quality is excellent, even on slow Internet connections.
• The platform can be used for free by anyone and it’s easy to create an account.
• Zoom is a standalone product with a singular focus rather than an add-on feature like Microsoft Teams or Google Hangouts.

Additionally, Zoom’s user experience is good, especially when it comes to joining a meeting. It’s hard to simplify that process much further than “here, click this link”. Overall, Zoom is easy enough to use, and it manages to keep its myriad of advanced features from getting in the way of hosting simple meetings.

UX Versus UI

With that said, Zoom is still far from perfect. While Zoom’s user experience (UX) is relatively frictionless, I’m still surprised by inconsistencies that exist in its user interface (UI). In my opinion, Zoom struggles with two main UI issues: consistency and clarity.

Consistency

For one, the website shares none of the design cues of the desktop and mobile apps. Buttons don’t even share the same names: the blue “Host a Meeting” link on the website competes with a large orange “New Meeting” button in the app. The meanings of both buttons are clear upon inspection, but this means that users have to become familiar with two separate interfaces before feeling comfortable using Zoom.

Some website features don’t appear in the app, and vice versa. For example, the “Previous Meetings” tab on the website doesn’t map back to anything in the “Meetings” section of the app. Similarly, the links in the navigation bar at the top of the app (Home/Chat/Meetings/Contacts) don’t match anything on the website.

Most frustratingly, the “Schedule a Meeting” interface on the website is substantially different from the one in the app. While the website prompts you to choose a start time and duration (and only allows you to adjust those times in half hour increments), the app asks for a start time and end time. The form options themselves are labeled differently: the start time is listed as “When” on the website and as “Date” in the app. At the bottom of the form, the advanced meeting options aren’t even presented in a consistent order between the two interfaces.

Finally, weird things occasionally happen while using Zoom. For example, when I went to unmute someone in a recent meeting, the participant list started arbitrarily reordering itself every few seconds. This made it almost impossible to choose the right person, as someone else would jump under my mouse cursor before I clicked. I’m still not sure if this was an intended feature, but it doesn’t make sense that it would be.

Clarity

On the clarity side, some of the buttons in the app aren’t immediately recognizable as buttons. The Join Audio/Share Screen/Invite Others trio is the most notable example of this issue:

I’ve been using Zoom for a while now, and every time I launch a meeting I have to remind myself that those three pieces of clip art are actually clickable. Additionally, since the introductory screen vanishes once other participants join, these buttons can’t be relied upon throughout the duration of a meeting.

Conclusion

Zoom’s UI does get one thing right: every button is clearly labeled with a description of what it does. While this may not be the most aesthetically pleasing choice, it makes it easy for untrained users to get started with Zoom. For that reason alone, I appreciate Zoom’s simple and unglamorous UI, but it’s still important that it isn’t so simplistic and inconsistent that it detracts from the user experience.

Further Reading

• A UX review of Zoom’s video call experience

Update 2/12/2020: Microsoft has reversed their decision to automatically install the Microsoft Search in Bing extension. The extension will still be made available but will not be automatically deployed with Office 365 ProPlus. The original post continues below:

Starting next month, Microsoft plans to use Office 365 ProPlus to push a browser extension for Google Chrome that will change users’ default search engines to Bing. Version 2002 of Office 365 ProPlus will forcibly install the Microsoft Search in Bing extension for all Chrome users who do not already use Bing as their default search engine.

Understandably, many system administrators are frustrated with the announcement, as unwanted browser extensions that change end-user settings are usually considered malware and are blocked accordingly. In fact, Microsoft’s own security tools already block dozens of programs that exhibit similar behavior.

On GitHub, users are responding to the change by opening issues in the OfficeDocs-DeployOffice repository. So far, it does not appear that Microsoft has responded to this influx of unsolicited feedback outside of publishing a blog post extolling the virtues of Bing.

Who Is Affected?

At this point, only businesses that have deployed Office 365 ProPlus are affected. Depending on the organization’s Office 365 license, ProPlus is the version of Office delivered to end-users when they install Office from the office.com portal. According to Microsoft, not all Office 365 plans include the ProPlus version of Office:

This extension is included only with Office 365 ProPlus. It isn’t included with Office 365 Business, which is the version of Office that comes with certain business plans, such as the Microsoft 365 Business plan and the Office 365 Business Premium plan.

Firefox Is Next

According to Microsoft, a similar extension for Firefox is also on the way:

Support for the Firefox web browser is planned for a later date. We will keep you informed about support for Firefox through the Microsoft 365 Admin Center and this article.

Removing The Extension

By making the extension an opt-out feature, Microsoft is putting the onus on system administrators to deploy a method for blocking its installation. While there are official ways to prevent the extension from being installed, there is no easy Microsoft-supported method for removing the extension once it has already been deployed. Instead, Microsoft recommends running the following command as an administrator on each affected machine using a script:

C:\Program Files (x86)\Microsoft\DefaultPackPC\MainBootStrap.exe uninstallAll

It should also be possible to blacklist the extension with the 3rd party Group Policy templates for Chrome and Firefox provided by Google and Mozilla.

Unfortunately, Group Policy and other enterprise management tools do not always apply to BYOD devices, leaving users who install Office on their personal machines with little recourse except to notice and remove the extension on their own if they find it undesirable.

Sources

• Microsoft Search in Bing and Office 365 ProPlus | Microsoft Docs
• Microsoft to force Chrome default search to Bing using Office 365 installer – The Verge
• Microsoft to forcibly install Bing search extension in Chrome for Office 365 ProPlus users | ZDNet