krypted.com

Tiny Deathstars of Foulness

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. screen-shot-2016-09-29-at-10-33-42-pm 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. screen-shot-2016-09-29-at-10-34-22-pm 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. screen-shot-2016-09-29-at-10-36-29-pm Here, click on the Log in button and enter a user with access to the server, preferably one who can create wikis. screen-shot-2016-09-29-at-10-37-12-pm 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. screen-shot-2016-09-29-at-10-37-40-pm At the “Create a new wiki” prompt, provide a name for the wiki and a brief description for it. screen-shot-2016-09-29-at-10-38-03-pm Click on Continue. screen-shot-2016-09-29-at-10-38-55-pm 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. screen-shot-2016-09-29-at-10-39-17-pm 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. screen-shot-2016-09-29-at-10-39-44-pm Once the setup is finished, you’ll see the Setup complete modal. Here, you can click on Go to Wiki button. screen-shot-2016-09-29-at-10-40-06-pm 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. screen-shot-2016-09-29-at-10-40-24-pm 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. screen-shot-2016-09-29-at-10-40-48-pm 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. screen-shot-2016-09-29-at-10-41-14-pm 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. screen-shot-2016-09-29-at-10-41-55-pm 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. screen-shot-2016-09-29-at-10-43-01-pm 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. screen-shot-2016-09-29-at-10-44-02-pm 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. screen-shot-2016-09-29-at-10-44-40-pm 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. screen-shot-2016-09-29-at-10-45-07-pm 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. screen-shot-2016-09-29-at-10-45-34-pm At the Upload File dialog, click on Choose File and then select a file to upload. screen-shot-2016-09-29-at-10-46-04-pm Click Upload when selected. screen-shot-2016-09-29-at-10-46-28-pm 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…

October 17th, 2016

Posted In: Mac OS X Server

Tags: , , , , , , , ,

Financial services is an interesting business when it comes to what you need to do to meet your regulatory requirements. With so much data and the services that enable you to access data moving to the cloud, it can be hard to keep up with how solutions meet any regulatory requirements you might have. At the end of the day, you’re primarily concerned about customer data leaking out of your environment and making sure that you can report on every single thing that happened in an environment. Whatever help we can provide in this article, make sure that you vet anything against what the individuals that review your regulatory requirements say. Click Here to Continue Reading More On blog.bushel.com

November 13th, 2015

Posted In: Bushel

Tags: , , , , ,

A common question we get in the media is whether or not an employer can look at email on an employees device. The answer is that an employer cannot use Bushel to see mail or content on a device. This isn’t to say that you can’t use your Exchange, Office 365, or Google Apps administrative accounts to view your email. But Bushel doesn’t have anything to do with that. Read More About Bushel, Privacy, And Your Users on the Bushel Blog Here  

November 1st, 2015

Posted In: Bushel, iPhone

Tags: , , ,

Bushel gives you three devices for free. But you can get more free devices if you like the product and choose to share it with your friends and family. To do so is pretty straight forward. Simply click on the Accounts icon in the sidebar and then click on the Profile tab. Here, towards the bottom of the screen, you’ll see the Referrals section. To Read More About Inviting Your Friends To Bushel To Get More Free Devices Forever on the Bushel Blog

October 13th, 2015

Posted In: Bushel, JAMF

Tags: , , , , , , , ,

How secure is your data on Bushel? Your data on anything is only ever as secure as your password. At Bushel, we take a lot of precautions to protect your data, including from ourselves. We time out your session, we encrypt your session on a per-transaction basis, and we encrypt your data while at rest on our servers (although consider it like the secure enclave in iOS, where we encrypt the data that needs to be encrypted – such as FileVault keys and activation lock bypass information). These basic precautions keep your communication with Bushel secure and prevent people from doing things like hijacking your session. Read My Article On How Bushel Protects Customer Data On The Bushel Blog

August 19th, 2015

Posted In: Bushel, iPhone, JAMF

Tags: , , , , , ,

One of those funny calls we get every now and then is about how to block someone from calling or texting you. There are two main ways to go about this. The first is if someone is in your contacts. The second is if someone isn’t. Read More About How To Block Phone Numbers on the iPhone On The Bushel Blog

August 12th, 2015

Posted In: Bushel, iPhone, JAMF, Mac OS X

Tags: , , , , , ,

My dad is a Superman. He makes his daily juggling act look effortless. He plays music, does tons of work around the house and in the garden, he’s always making new artwork, and is pretty much always doing something. He has an incredible green thumb, growing everything from beautiful Southern flowers to pear trees, ivy – and the occasional herb or grape. And these days, he shares it all on Facebook, complete with witty banter and a like for pretty much every one of my posts. Bushel, A Great Gift For People That Need To Save Time!

July 14th, 2015

Posted In: Bushel, iPhone, JAMF

Tags: , , , , ,

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 Yosemite Server (the Apple Server app running on 10.10). 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. wiki1 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. wiki2 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. wiki3 Here, click on the Log in button and enter a user with access to the server, preferably one who can create wikis. wiki4 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. wiki5 At the “Create a new wiki” prompt, provide a name for the wiki and a brief description for it. wiki6 Click on Continue. wiki7 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. wiki8 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. wiki9 Once the setup is finished, you’ll see the Setup complete modal. Here, you can click on Go to Wiki button. wiki10 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. wiki11 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. wiki12 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. wiki13 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. wiki14 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. Wiki15 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. Wiki16 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. wiki17 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. wiki18 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. wiki19 At the Upload File dialog, click on Choose File and then select a file to upload. wiki20 Click Upload when selected. wiki21 Then from the Finder of an OS X 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. Overall, the ability to edit, upload and view documents from the Wiki is a great new feature in OS X Yosemite Server, worthy of checking out if you haven’t already! 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 a tech firm 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 OS X 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…

October 16th, 2014

Posted In: Mac OS X, Mac OS X Server

Tags: , , , , , , , , , , ,

Your Bushel can serve a wide range of industries and sizes of organizations, including field services. If you have 10, 50 or 1,000 devices that need managing, Bushel can be tailored to fit the needs of many. A common setup for a field services operation includes the following attributes: Learn More About How Bushel Is Used In Field Service and Engineering…

September 16th, 2014

Posted In: Bushel

Tags: , , ,

The article I did a few weeks ago on customizing the Mac OS X Server Wiki banner seems to have been a little incomplete. I discussed customizing the banner for a full web browser. However, the banner looks differently when viewed from an iPhone. I’ve had a couple of questions about how to customize the banner for iPhone so I figured I’d finish what I started. As I mentioned in the last article, you can simply customize (or replace) the banner-bg.png file located in the /usr/share/collaboration/css/serverhome_static/img directory. This will alter the appearance when viewed from a full web browser. You can also simply edit the following files (same directory) to further alter the appearance (including those for iOS):
  • footer-bg.png – The Apple logo on the initial splash page.
  • iphone-banner-bg.png – The banner file to customize for when users are accessing the splash page from iPhone rather than the browser (what this article was originally about). As with the last article, here’s a sample ArtText document for customizing the banner.
  • iphone-footer-bg.png – The footer image from iPhone.
  • iphone-service-button.png – The background for services from iPhone (tip: make sure to leave something in place of the little blue arrows so people know to click on these).
  • iphone-service-icons.png – Smaller version of the service-icons.png, without reflection (Note: you may have seen clips of these in presentations I have done).
  • more-bg.png – The arrow beside the View All per service on the opening page.
  • service-bg.png – The background for the various services you have enabled on the initial landing page.
  • service-icons.png – collection of the service icons that indicate what an item is. These include the icon for blog, wiki, mail, change password, Podcast Producer and iCal. While these may seem generic I have to give the designers who made them credit as I have yet to make anything approaching the quality of these so I almost invariably leave them as-is.
If you want to increase from 320px width for iPhone to 640 for iPad or something like that you’ll need to track down the css files. The css file for the iPhone is in the /usr/share/collaboration/css/serverhome_static directory and called (oddly enough) iphone.css. The css file for overriding body content for standard browsers is the overrides.css in that same directory. These allow you to customize font, text size, background, etc. The iphone css even has a different section for landscape view. If you want to get even more custom than just messing around with the splash page then go up another directory to /usr/share/collaboration/css. Here, you’ll find images and css files for each of the services exposed through the teamserver, including proxy, mobile, ical, emailrules and directory, including one of my fav 5, spinner.gif (seen below), which is a spinning symbol similar to that used at boot in Mac OS X. If you like living on the edge (no pun intended) then you can hop up yet another directory and start messing around with live html files. Or in the /usr/share/collaboration/themes you can find the css files and images that make up the default Apple-supplied themes. Apple provides a document on managing the themes, but the gist is that you can copy the wireframe theme you find there and rename the copy. Then open the theme.plist file inside the theme and find the selectable key, making it true instead of false. Once you’ve saved that file, restart the service to see (and use) your new theme. There are lots of other cool keys in the theme.plist, which allow you to add or remove the search fields, HotList, theme name (and displayName), change the height or width of the banner, add other sidebar items, etc. It’s not WordPress so don’t expect to download awesomeo widgets, but then it’s much more elegant than most Content Management Systems are out of the box and should just work. This isn’t to say it isn’t extensible. You can add JavaScript and XSL (ie – for FileMaker Server integration), but this can start getting somewhat complicated. One interesting note is that much of the Dashboard widget example code will run here… Be warned, with each level of the hierarchy you traverse upwards you are more likely to find a software update blowing out your code changes (especially when you get to /usr;). Which brings up an interesting point – backup your changes. Make a good backup of the whole thing before you start hax0ring around in there and then, make sure that if you do any customizations in /usr/share/collaboration that you back up that directory (I mean, you are backing up the rest of the server, right?!?!). The other directory that needs to be backed up is /Library/WebServer. This is where the actual HTML pages are stored. In here, you’ll find the Documents folder, and in there you’ll find the index.html page. If you’ve been monkeying around with the files I mentioned earlier then a key item that you’re going to want to change is the footer, where Apple asserts their copyright. This is down in the div class=”footer” section. You can also use this file to manually disable certain services. For example, you’ll see the podcastcapture section. Now, you would likely rather remove these from Server Admin if you can, but I can see edge cases (doh, again no pun intended) where you might rather edit it here. There are also some css files in here to control various ways that pages appear (although the appearance inside service boxes is configured using the files referenced earlier). Anyway, I want to end this by saying that out of the box the Wiki, Blogs, Podcast Producer (if you’re using Open Directory) and other parts of the teams server works great out of the box. It’s pretty sleek as it is and other than a footer or banner here and there I’m actually not a huge proponent of heavy customization. But if you must (and many must) then hopefully this article helps get ya’ started!

August 14th, 2010

Posted In: Mac OS X Server

Tags: , , , , , , , ,

Next Page »