A wiki is a repository of dynamically created and managed content, or content created or edited by multiple users collaboratively. This article is about using the wiki service in macOS Server 5.2 (the Apple Server app running on 10.12/Sierra). I reference file services with WebDAV because it is a very nice integration piece that I think a lot of people will find pretty beneficial.
To get started with the Wiki service, first turn it on. This one isn’t heavily dependent on host names (other than being able to access the server from a browser) or directory services (other than being able to authenticate users, but local accounts are perfectly functional) and it doesn’t require the Websites service to be running as well. One should always have good working directory services and host names, still…
To enable the service, open the Server app and click on Wiki in the list of SERVICES in the List Pane.
There are two configuration options. The first is to select who is able to create wikis. Use the “Wikis can be created by” drop-down list to select “all users” if anyone with an account on the server should be able to create a wiki or “only some users” to bring up the Wiki Creators screen.
If only some users can create new wikis, use the plus sign (“+”) at the Wiki Creators screen to add users and/or groups to the list of users that can create wikis. Click on OK when all users and groups that can create wikis are added. In a school I would imagine that only teachers or IT staff would be able to create wikis. Once a wiki is created, pages inside the wiki can still be created by non-wiki creators.
The other option available is the handy dandy WebDAV interface to the wikis. When you enable this option, you can connect to a server from OS X or iOS via WebDAV and access files in each wikis document repository. To be clear, this option doesn’t provide access to the user documents, but does provide access to the wiki documents. We’re going to check the box for “Enable WebDAV access to Wiki files” and then click the ON button.
Once the service starts, click on the View Wiki link in the Wiki workspace in Server app.
Here, click on the Log in button and enter a user with access to the server, preferably one who can create wikis.
At the Wikis page, you will then see a list of all wikis you have access to. Note that the previous screen showed one wiki and now we see two. That’s because one of the wikis has permissions that allow “All unauthenticated users” access to the wiki, which we’ll describe shortly. The first thing most administrators will do is create a wiki. To do so, click on the plus sign (“+”) icon on the web page and at the resultant screen, click on New Wiki.
At the “Create a new wiki” prompt, provide a name for the wiki and a brief description for it.
Click on Continue.
At the Set permissions screen, enter each user or group to provide access to edit and view wiki pages. Here, you’ll have the options for Read & Write (users can view and edit pages in the wiki), Read only (users can only view the contents of your pages) and No access (users have no access to the wiki). There is a group for All logged in users, which includes every user with access to the server and another for All unauthorized users, which includes guests to the server. Once you’ve given the appropriate permissions, click on Continue.
Note: You don’t have to get this perfect now as you can always edit these later.
At the Set Appearance screen, you can choose an icon for the wiki (shown in the wiki list and when you open the wiki) as well as a color scheme for the wiki. Choose the appropriate appearance for your wiki (again, you can always change this later) and then click on the Create button.
Once the setup is finished, you’ll see the Setup complete modal. Here, you can click on Go to Wiki button.
Once you’ve created your first wiki, let’s edit it and customize the content. To do so, click on it from the list of available wikis. Click on the cog-wheel icon and then Wiki Settings… to bring up the Wiki Settings page.
Here, you’ll see the previously entered name and description as well as options to enable Calendar (only available if Calendar Server is running on the server) and Blog, which enables a blog service for the wiki (wiki administrators can post blog entries to the wiki). Click on Appearance.
Here, you will have the previous two options as well as the ability to upload a banner (which should be 62 pixels high) and background for each wiki.
Click on Permissions. Here, you’ll see the permissions previously configured as well as options to configure who can comment on articles (nobody disables comments completely) in the wiki and whether comments require approval (moderation).
Click on Save. Now, let’s edit the splash page. To do so, click the pencil icon in the top navigation bar.
At the edit screen, the top nav bar is replaced by a WYSIWIG editor for managing the page. Here you can justify, link, insert media and of course edit the text you see on the screen. I recommend spending some time embedding links, inserting tables, making text look like you want it to and editing the content to reflect the purpose of the wiki. Click Save when you’re done. Click the pencil again to edit it, and let’s create a new wiki page. Keep in mind that link wikipedia, each page should be linked to from other pages in the order they should be read. Unlike most wikis, there’s actually an index page of all the articles, which can come in handy.
From the edit page, to create a new page and link to it, enter some text (or lasso some) that you’ll use as the link to access the new page you’re creating. Then click on the arrow and select “New page.”
Note: Use Enter URL to link to an existing page or an external website, instead of creating a new page.
At the New Page screen, provide a name for the new page (the lasso’d text automatically appears as the Page Title) and click on the Add button.
Click Save and then click on the newly created link. You can now edit the new page the same way you edited the previous pages. Click on the disclosure triangles in the right sidebar to Comment on articles, link articles to related articles, tag articles and view editing history.
Now for the fun part. Click on Documents. Here, you’ll see the pages you already created. Click on the plus sign and select the option to Upload File to the wiki.
At the Upload File dialog, click on Choose File and then select a file to upload.
Click Upload when selected.
Then from the Finder of a macOS client, use the Go menu to select “Connect to Server”. Enter the name or IP of the server and then click on Connect.
Assuming you can access the server, you should then be prompted for a username and password. Enter it and click Connect. Eventually, the file(s) will display (it can take awhile according to your network speeds and how many files are in the directory). You can connect to this same screen through an iPad using a 3rd party WebDAV client or the build in options in Pages.
Managing wikis is as easy as its ever been, with the new options for appearance being a nice add-on. Active Directory integration is as easy as binding the server to Active Directory and using the accounts listed in Permissions of pages.
Now that iOS devices can edit wikis and many of the traditional word processing options are available in the wiki editor, consider what the Wiki can be. Could it replace text editing apps for iOS? Could the Wiki allow for more collaborative documents than a Word or other document editor? Could it keep from getting eaten like the rest of the homework? Could the comments in the Wiki be a good way for teachers to have students write responses to materials? Could the Wiki and the document management features allow your workers to access human resources documents and employee manuals? I know plenty of tech firms that use wikis to track information about the systems they manage.
Once you have all of this information, upgrading can seem downright scary. But fear not, there’s Carbon Copy Cloner. And once you’ve cloned, there’s wikiadmin. When doing an upgrade in place, the Wiki service is pretty straight forward to upgrade, but in many cases, due to aging hardware, wiki services are moving from an older computer to a newer computer. This can be done in one of two ways. The first is to “migrate” the data by copying the Collaboration folder onto the new system. The second is to “export” and “import” the data. I usually recommend doing a migrate where possible, so we’ll start with that method.
Note: Before getting started, make sure that the directory services side of things is good. If a user or group lookup for an object that owns, edits or has commented on a wiki fails then that wiki probably shouldn’t be migrated. Use the dscl or id commands to confirm that lookups are functioning as intended.
To migrate wikis from one server to another, first copy the Collaboration directory to the new server. In this example, the directory has been dropped onto the desktop of the currently logged in user. To migrate the data once copied, use the wikiadmin command, along with the migration option. The option requires the path to the Collaboration folder, defined with -r, as follows:
sudo wikiadmin migrate -r ~/Desktop/Collaboration
When moving wikis, you can take the opportunity to get rid of a few you don’t want (such as that test wiki from way back when). Or administrators may just choose to move a single wiki to a new server in order to split the load across multiple hosts. When doing so, use the same command as earlier, along with the name of each wiki that is being moved, along with the -g option. For example, if moving the Legal wiki:
sudo wikiadmin migrate -r ~/Desktop/Collaboration -g Legal
The second way of moving wikis around is to export and then import them. To do so, first export wikis on the old server, using the wikiadmin command along with the export option, which requires an –exportPath option and needs to be done, on a wiki-by-wiki basis. So to export that Legal wiki to a file called LegalWikiTMP on the desktop:
sudo wikiadmin export -g Legal --exportPath ~/Desktop/LegalWikiTMP
Next, copy the wiki to the new server and import it, using the import option along with –importPath to identify where the file being imported is located. Using the same location, the command would then be:
sudo wikiadmin import -g Legal --importPath ~/Desktop/LegalWikiTMP
Note: The ability to import a wiki also allows for an API of sorts, as you can programmatically create wikis from other sources. The ability to export also provides a way to move into another wiki tool if you happen to outgrow the options provided in Server and need to move to something more robust.
There is another way to move wikis, using pg_dump, copying the data and then using pg_restore to import the data once you’ve created the tables. This way is, in my opinion, the last resort if the standard wikiadmin commands aren’t working. In my experience, if I’m doing the migration this way then I’ve got other, bigger issues that I need to deal with as well.
These commands work best when the wiki service has been started so that the databases are fully built out. To start the wiki service from the command line, use the serveradmin command instead of the wikiadmin command. The serveradmin command is used with the start option and then wiki is used to indicate the wiki service, as follows:
sudo serveradmin start wiki
The service can also be stopped, swapping out the start option with a stop option:
sudo serveradmin stop wiki
In a few cases (this is the main reason I’m writing this article), the attachments to wikis don’t come over during a migration. To migrate the files that are used for QuickLook, downloading attachments, etc, use the serveradmin command to locate the directory that these objects are stored in:
sudo serveradmin settings wiki:FileDataPath
The output identifies the directory where these objects are stored. Placing the contents in the same relative path as they are to the output of the same command on the target server usually results in restoring them. Once moved, use the fixPermissions option to repair the permissions of any files from the source (if any changes to account IDs are encountered such as an export/import rather than an archive/restore in OD this can lead to odd issues:
sudo wikiadmin fixPermissions
Also use the rebuildSearchIndex option with the wikiadmin command to fix any indexing, once the permissions have been repaired:
sudo wikiadmin rebuildSearchIndex
And finally use resetQuicklooks to clear any cached Quicklook representations of objects that have been inserted into a wiki and might not display properly using Quicklook (you know you might need to do this if they look fine when downloaded but look bad with Quicklook even though QuickLook on the server can view the files just fine):
sudo wikiadmin resetQuicklooks
When done properly the migration can take awhile. Keep in mind that every tag, every article, every edit to every article and basically everything else is tracked inside the tables that you’re moving. While there might not be a ton of data in the Collaboration directory or in an export, all of the data needs to go to the right location. This can take a little time in environments that have a lot of articles, even if they’re really short articles…
krypted October 17th, 2016
Posted In: Mac OS X Server
Apple, Blog, cache, calendar integration, export, import, macos server, rebuild, wiki server
Pow is a Rack server for OS X. It’s quick and easy to use and lets you skip that whole update an Apache file, then edit /etc/hosts, ethane move a file, then run an app type of process. To get started with Pow, curl it down and pipe it to a shell, then provide the password when prompted to do so:
odr:~ charlesedge$ curl get.pow.cx | sh
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 9039 100 9039 0 0 10995 0 --:--:-- --:--:-- --:--:-- 10996
*** Installing Pow 0.5.0...
*** Installing local configuration files...
*** Installing system configuration files as root...
*** Starting the Pow server...
*** Performing self-test...
For troubleshooting instructions, please see the Pow wiki:
To uninstall Pow, `curl get.pow.cx/uninstall.sh | sh`
To install an app into Pow, create a symlink to it using ln (assuming ~/.pow is your current working directory):
ln -s /path/to/myapp
Then just open the url, assuming my app is kryptedapp.com:
Pow can also use ~/Library/LaunchAgents/cx.pow.powd.plist to port proxy. This allows you to redirect different apps to different ports. When pow boots, it runs .powconfig, so there’s a lot you can do there, like export, etc. Once you’re done testing out pow, if you don’t decide it’s awesome, remove it with the following command:
curl get.pow.cx/uninstall.sh | sh
krypted February 2nd, 2015
Posted In: Mac OS X, Mac OS X Server, Mac Security, Mass Deployment, Ubuntu, Unix, WordPress
environment variables, export, MAC, os x, OS X Server, rails, rb, Ruby, run a rack server on os x
The LDIFDE utility exports and imports objects from and to Active Directory using the ldif format, which is kinda’ like csv when it gets really drunk and can’t stay on one line. Luckily, ldif can’t drive. Actually, each attribute/field is on a line (which allows for arrays) and an empty line starts the next record. Which can make for a pretty messy looking file the first time you look at one. The csvde command can be used to export data into the csv format instead. In it’s simplest form the ldifde command can be used to export AD objects just using a -f option to specify the location (the working directory that we’re running the ldifde command from if using powershell to do so or remove .\ if using a standard command prompt):
ldifde -f .\ADExport.ldf
This exports all attributes of all objects, which overlap with many in a target Active Directory and so can’t be imported. Therefore, you have to limit the scope of what you’re exporting, which you can do in a few ways. The first is to only export a given OU. To limit, you’ll define a dn with a -d flag followed by the actual dn of the OU you’re exporting and then you’d add a -p for subtree. In the following example we’ll export all of the objects from the sales OU to the SalesOUExport.ldf file:
ldifde -d "OU=sales,DC=krypted,DC=local" -p subtree -f .\SalesOUExport.ldf
Restoring objects still results in an error that the server is “Unwilling To Perform” the import because “The modification was not permitted for security reasons.” Basically, this just means “hey I’m not going to import into some of the fields that I know I have to reserve for objects managed by the system, such as creation date (whencreated), last changed date (whenchanged), etc. So we can take some of these and omit them from our export. You can use ADMT or just look at an ldif or csv file to determine which attributes from the schema that you think need to be omitted, but at a minimum it should include objectguid, uSNCreated, uSNChanged, whencreated and when changed (and a lot of the Exchange attributes if you’ve extended the schema for your forest). To omit use the -o and enclose the omitted attributes in parenthesis. In the following example, we’ll export to the SalesOUExportO.ldf file, and add the -o flag to the previous command:
ldifde -d "OU=sales,DC=krypted,DC=local" -p subtree -o "objectguid,uSNCreated,uSNChanged,whencreated,whenchanged" -f .\SalesOUExportO.ldf
You can also omit using the -m flag, which includes only the essential attributes, so we’ll add that to the command as well:
ldifde -d "OU=sales,DC=krypted,DC=local" -p subtree -o "objectguid,uSNCreated,uSNChanged,whencreated,whenchanged" -m -f .\SalesOUExportO.ldf
Use the -l option to limit the attributes being exported to only those specified.
The -r option restricts the export to a given category or class. For example, if we only wanted to export users, we can restrict to objectClass-User
ldifde -d "OU=sales,DC=krypted,DC=local" -p subtree -r "(objectClass=user)" -o "objectguid,uSNCreated,uSNChanged,whencreated,whenchanged" -m -f .\SalesOUExportOM.ldf
Now I’m feeling like we have a good restricted set of data that we’re moving. Let’s go ahead and give importing a shot on a target server. To do so, we’ll just use -i to specify this is an import, followed by -k to say “don’t stop if you have a problem with just one record”, -f to define a file and -j to write a log. We’ll use the working directory for the file path and the log path, assuming this is being done by calling the .exe from within powershell:
ldifde -i -k -f .\SalesOUExportOM.ldf -j .\
Once complete, the exported objects should appear once you close and re-open Active Directory Users and Computers. You can also export one object, then programmatically create objects in an ldif file as needed by importing them into Active Directoryusing ldifde.
krypted March 20th, 2014
Posted In: Active Directory, Windows Server
attributes, command prompt, csvde, export, import objects into active directory, ldifde, Organizational Unit, powershell, schema, script
The netsh command can be used to manage network interfaces, control routing and one of the lesser-used features that I’ve seen are to import and export service settings with Windows Servers. This can be especially helpful if you need to normalize data for import into another Windows server or to be normalized for use with another server platform. To export your DHCP information, from a command prompt in Windows you would run the netsh command along with the service you are exporting settings for (WINS, DHCP, etc). After the service identifier you would indicate the action being performed (ie – import or export in this context), followed by a file to dump the data to and finally the subset of the data (we’ll use all for convenience sake and throw the data into an easily locatable place on the root of the C Drive, which you obviously need access to for the copy):
netsh dhcp server export C:dhcpsettings.txt all
Now that you have exported the data, you can copy it to your other Windows Server box and import using the exact same command (assuming the file lives in the same place) but swapping out your export for an import:
netsh dhcp server import C:dhcpsettings.txt all
DNS is a different beast given that there is a special dnscmd command for managing that service. To export your DNS information:
dnscmd ServerName /enumrecords zonename @ /type A /detail > c:mydnssettings.txt
Or in CSV:
dnscmd /enumrecords zonename @ /Type A /additional > c:mydnssettings.csv
One of the most used services for Windows servers though, is as a filer. File shares are stored in a registry key at HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesLanmanServerShares. You can browse here using regedt32 and then export the key. You would then use the Import option in the File menu (Windows 2003 uses Import whereas previous versions use Restore).
Note: Restoring this data will nuke and pave your existing shares on the box you’re running it on and in most cases you will need to restart appropriate services and/or the box to see the new settings.
krypted August 10th, 2010
Posted In: Windows Server
dnscmd, export, export settings, import, netsh, servername, Windows Server, zonename
It really helps me to see different types of entries in the Terminal listed with different colors. I don’t go for listing everything that you can list as a different color though, as it starts looking a bit like a circus in Terminal when I do. If you want to colorize your terminal in Mac OS X there are two main ways to do so; both will require altering your .bash_profile (or creating if it’s not already there).
To get started, go to your home folder from within Terminal and open .bash_profile from your favorite text editor. If it doesn’t exist then the text editor should create a new file when you save it. Now that you’ve created the .bash_profile paste these two lines in there:
The above export can be seen as having two aspects. The first is the position. There are a total of 11 positions, with a foreground and a background being listed in that order, for each position, resulting in 22 total letters. The following represents each position, in sequence:
- Symbolic link
- Special block
- Special character
- Executable w/ setuid set
- Executable w/ setgid set
- Directory that is writable to others w/ sticky bit
- Directory that is writable to others w/out sticky bit
Next, consider the colors that are used. These include:
- a black
- b red
- c green
- d brown
- e blue
- f magenta
- g cyan
- h light grey
- x default foreground or background
Additionally, each of these colors can be used in upper case, resulting in a bold version of the same color. So if we want everything else listed with the default colors except for directories and we wanted those listed in red, we could use the following LSCOLORS line:
Now let’s say that we’re going to have our executables listed in blue, directories in red and everything else in the default colors:
Finally, let’s say that we’re going to retain those two settings but also have the special block with a red background and black text:
Additionally you can customize the colors of your prompt (and customize how it looks and what’s included. I’ll get to the prompt customization later though, as I’ve got a little football to go watch… Favre + Vikes!
krypted September 13th, 2009
Posted In: Mac OS X, Mac OS X Server, Ubuntu, Unix
.bash_profile, bash, colorize terminal, customize shell, export, LSCOLORS, prompt, terminal color