OS X has a built-in web server called Apache. It’s been there for a long, long time. Once upon a time, you could enable web sharing using System Preferences. This is no longer a feature in the Sharing System Preference pane, but you can actually enable it quicker than you could before. To do so, we’ll use apachectl:
To then stop the web server:
To see the apache status:
The default site is stored in /Library/WebServer/Documents. You can then edit this there, or replace the index.html.en file with a file/hierarchy that you wish to have.
krypted December 22nd, 2015
The tools to automate OS X firewall events from the command line are still stored in /usr/libexec/ApplicationFirewall. And you will still use socketfilterfw there for much of the heavy lifting. However, now there are much more helpful and functional options in socketfilterfw that will allow you to more easily script the firewall.
Some tricks I’ve picked up with the Mac Firewall/alf scripting:
In /usr/libexec/ApplicationFirewall is the Firewall command, the binary of the actual application layer firewall and socketfilterfw, which configures the firewall. To configure the firewall to block all incoming traffic:
/usr/libexec/ApplicationFirewall/socketfilterfw --setblockall on
To see if block all is enabled:
The output would be as follows, if successful:
Firewall is set to block all non-essential incoming connections
A couple of global options that can be set. Stealth Mode:
/usr/libexec/ApplicationFirewall/socketfilterfw --setstealthmode on
To check if stealth mode is enabled:
/usr/libexec/ApplicationFirewall/socketfilterfw --setloggingmode on
You can also control the verbosity of logs, using throttled, brief or detail. For example, if you need to troubleshoot some issues, you might set the logging to detail using the following command:
/usr/libexec/ApplicationFirewall/socketfilterfw --setloggingopt: detail
To start the firewall:
/usr/libexec/ApplicationFirewall/socketfilterfw --setglobalstate on
While it would be nice to think that that was going to be everything for everyone, it just so happens that some environments actually need to allow traffic. Therefore, traffic can be allowed per signed binary. To allow signed applications:
/usr/libexec/ApplicationFirewall/socketfilterfw --setallowsigned on
To check if you allow signed apps:
This will allow all TRUSTEDAPPS. The –listapps option shows the status of each filtered application:
To check if an app is blocked:
/usr/libexec/ApplicationFirewall/socketfilterfw –getappblocked /Applications/MyApp.app/Contents/MacOS/myapp
This shows the number of exceptions, explicitly allowed apps and signed exceptions as well as process names and allowed app statuses. There is also a list of TRUSTEDAPPS, which will initially be populated by Apple tools with sharing capabilities (e.g. httpd & smbd). If you are enabling the firewall using a script, first sign your applications that need to allow sharing but are not in the TRUSTEDAPPS section by using the -s option along with the application binary (not the .app bundle):
/usr/libexec/ApplicationFirewall/socketfilterfw -s /Applications/MyApp.app/Contents/MacOS/myapp
Once signed, verify the signature:
/usr/libexec/ApplicationFirewall/socketfilterfw -v /Applications/MyApp.app/Contents/MacOS/myapp
Once signed, trust the application using the –add option:
/usr/libexec/ApplicationFirewall/socketfilterfw --add /Applications/MyApp.app/Contents/MacOS/myapp
To see a list of trusted applications. You can do so by using the -l option as follows (the output is pretty ugly and needs to be parsed better):
If, in the course of your testing, you determine the firewall just isn’t for you, disable it:
/usr/libexec/ApplicationFirewall/socketfilterfw --setglobalstate off
To sanity check whether it’s started:
Or to manually stop it using launchctl (should start again with a reboot):
launchctl unload /System/Library/LaunchAgents/com.apple.alf.useragent.plist
launchctl unload /System/Library/LaunchDaemons/com.apple.alf.agent.plist
If you disable the firewalll using launchctl, you may need to restart services for them to work again.
krypted July 16th, 2015
Installing Active Directory services is arguably one of the first things done on many a Windows Server. And for well over a decade you could unbox, update, run dcpromo and be done with much of that. While the wizards are still there, in the case of Windows Server 2012, the process has changed ever-so-slightly. To install a domain controller in Windows Server 2012, start with Server Manager. This new tool is the place where you start many a process in a Windows Server now, and Active Directory is no different.
To get started, first open Server Manager.
From Server Manager, click on the Manage menu and select Add Roles and Features. At the Before you begin screen in the Add Roles and Features Wizard, click on Next.
At the Installation Type screen, choose Role-based or feature-based installation and click Next.
At the Server Selection screen, choose the server you’d like to install the Active Directory role on and then click Next. If you only have one server then you should only have one listing here.
There are a number of Roles a domain controller can have. For many environments, a simple Domain Services role will be sufficient, especially on the first 2012 server in the environment. To select this, at the Server Roles screen, choose Active Directory Domain Services and then click on Next.
A sanity check will run to verify all the required Features and other Roles are installed. If not, you’ll be presented with a list of items that will be installed in support of the Role being deployed. Click Add Features for most environments, unless you have the tools to manage the Role installed elsewhere.
Back at the Server Roles screen, click Next, unless you’d like to install other Roles as well.
At the Features screen, click Next, unless you’d like to install other features as well.
At the AD DS screen, click Next.
At the Confirmation screen, click Install. You can also tell the server to restart automatically here, so do that as well.
Once the installation is complete, you’ll see a yellow icon indicating that something needs to happen with the server. The menu that appears contains a link to promote the server to a domain controller. Click the link to bring up the Deployment Configuration wizard.
At the Deployment Configuration screen of the wizard you can choose whether to add the domain controller to an existing domain or create a new forest. In this case, we’ll select the “Add a new forest” option. When highlighted, you will be able to provide a name for the domain. here we use krypted.com. Once the name is provided, click Next.
At the Domain Controller Options screen, choose whether the server will be an AD Integrated DNS Server, a Global Catalog server, possibly a Read only domain controller and provide a Directory Services Restore Mode (DSRM) password used to restore the environment in case it fails. Also, choose the functional level of both the domain and forest. Because this is a new environment with no 2003 to 2008 servers we will leave the levels set to Windows Server 2012. Click Next when you’re satisfied with your entries.
If you decided to enable DNS, you will have the option to also install DNS delegation which you should do if possible, in most environments. Click Next.
At the Additional Options screen, provide a NetBIOS name. This is usually a 8 character or less rendition of the same domain name, often used in legacy tools or prepended to usernames and passwords when namespace collisions occur with account names. When you’ve provided the name, click Next.
At the Paths screen, indicate where you want the directories that contain the Active Directory files stored. Most environments can leave these to the default settings and click Next.
At the Review Options screen, click Next provided that all of the options match the information you provided/desire.
At the Installation screen, click Install and watch the Progress (takes a minute or three usually to complete).
Once completed, open the Tools menu in Server Manager to see the tools formerly available in the Administrative Tools section of the Start menu, including Active Directory Domains and Trusts, Active Directory Power Shell, Active Directory Sites and Services and Active Directory Users and Computers, which mostly look like they’ve looked for a long time (but with a pretty blue frame around the screen).
Additionally, there’s an Active Directory Administrative Center, which provides quick and easy access to a number of features from other tools and allows you to change domain controllers, raise the domain/forest functional levels (useful when upgrading from previous incantations of Active Directory), etc.
krypted August 12th, 2013
The Dock is, by default, anchored to the middle of the screen. However, in some environments you may want to have it skewed to one side of the screen. In order to do this Apple provides the ability to use pinning. Pinning will pin the dock to the start, end or middle; by default it’s pinned to the middle. If you pin the dock to the start and it’s either on the right or left side of the screen then it will appear to be skewed towards the top. If you pin it to the start and it’s on the bottom then it will skew to the left of the screen. In order to pin the dock to the start you can use the following command:
defaults write com.apple.dock pinning -string start
Once you’ve changed the pinning position you will not immediately see a change. First you need to kill the Dock. You can do this by rebooting or simply using the killall command using Dock as a pattern:
If you pin the dock to the end and it’s either on the right or left side of the screen then it will appear to be skewed towards the bottom of the screen. If you pin it to the end and it’s on the bottom then it will skew to the right of the screen. In order to pin the dock to the end you will use the following command:
defaults write com.apple.dock pinning -string end
To go back to the default settings, just pin the dock to the middle:
defaults write com.apple.dock pinning -string middle
krypted November 5th, 2009