You are not logged in.

Announcement

[2017.09.08] DeployStudio build v1.7.8 (checksum, release note).
[2016.08.26] DeployStudio build v1.6.19 (release note).
[2013.02.23] DeployStudio last universal build v1.5.17 (release note).

#1 2015-06-12 00:17:26

ebonweaver
Member
Registered: 2015-06-09

Inappropriate Repository and other missing documentation

Is there actually documentation anywhere for the current version on the current OS?  The documentation on the main site is 5 years old and no longer relevant.  We have been fumbling around trying to get DS to work for days and have barely made any progress.  If anyone has a good setup/ config guide for DS on 10.10 we'd really appreciate it being shared and being posted to replace the old irrelevant docs.
Thus far we have pieced together that you need to use Server.app to enable NetInstall and File Sharing because otherwise things don't work.  Critical omissions it would seem.
We have gotten a netboot set to create, and got a system to boot from it, but then we get this error message and can do nothing more on the client:
Innapropriate Repository
You need a network repository to enable this computer to access imaging data.
Please contact the DeployStudio Server adminitrator in order to fix the repository setup.

Ok, well, that's clear as mud.  We are the administrators, and there is nothing in DS about repository setup, so what is this talking about?  Presumably it means the /Library/DeployStudio Repository folder which it should have set up when building the system, but apparently did not?  Various Googling led to turning on File Sharing because this was not enabled by DS (or mentioned) but that didn't help.  We then tried changing permissions on that Shared Folder as some said it has to be open to everyone, so we set it to read write.  That didn't help, and made the folder into a file in the Finder for some reason, which can not not be accessed even by the admin account that owns it.  Seems Apple is to blame on that one most likely for creating a system that corrupts it's own permissions?

So, does anyone know the missing info on how a repository is set up, and happen to know how to unscrew Apple's mess of folder permissions to make this work again without rebuilding from scratch?

Offline

#2 2015-06-12 00:23:49

ebonweaver
Member
Registered: 2015-06-09

Re: Inappropriate Repository and other missing documentation

Nevermind on the permissions, figured out you have to remove everyone to make it behave normal.  Thanks Apple...

As for this repository, more and more makes no sense to me.  The client seems to want to access it by http, but that seems really odd.  Shouldn't it be trying to get to the shared folder by afp?  Websites is enabled in Server, so I can only assume DS did that (why not enable File Sharing then??) but the address listed is .local instead of the FQDN, which seems broken as well, with seemingly no way to fix it...  All very odd, I would have thought DS was around long enough to be more refined than this.

Offline

#3 2015-06-12 08:27:02

homerdjw
Member
From: London, England
Registered: 2013-01-24
Website

Re: Inappropriate Repository and other missing documentation

Hi Edonweaver,

Just to confirm, did you run the deploy Studio assistant to help setup your server? It's been a good 6-12 months since I've done a fresh DS install but I believe that during this assistant you can configure the Repository path and protocol.

As for the server address, this would have been requested as part of the NetBoot Set creation. May I suggest you run through this again?

Just as a word of warning, the DNS solution (discoveryD) in OS X Yosemite is a little.....temperamental (hence why they're are strong rumours that they are replacing it with the previous version, mDNS responder). If it's having issues, I'd suggest creating the NetBoot image with the server's IP address, if only as a test.

I hope these points help you!

Darren

Offline

#4 2015-06-12 22:20:28

Meat
Member
From: SF CA US
Registered: 2009-02-04

Re: Inappropriate Repository and other missing documentation

> ebonweaver wrote:

> Thus far we have pieced together that you need to use Server.app to enable NetInstall and File Sharing because otherwise things don't work.  Critical omissions it would seem.
So, yes. The documentation is old.
Version 2.0 of the documentation specifies on page 11, item "i."
    Enable AFP, Netboot and Open Directory.

AFP (like SMB and NFS) is a file sharing protocol File Sharing uses, and Netboot corresponds to NetInstall. Open Directory, or Directory Services

> We are the administrators, and there is nothing in DS about repository setup, so what is this talking about?  Presumably it means the /Library/DeployStudio Repository folder

Whoa there, pardner! Where did you get "/Library/DeployStudio Repository" from?
You can, and should create a folder you will be using as a repository. It could be in /Library/ I guess, but that seems unnecessarily odd.
If you have no second drive for your server, then just create a folder (somewhere logical like the root level), share the repository folder, configure DeployStudio to use that repository.

Try to avoid using the repository as a simple file share for transferring files between coworkers, friends, and family

If you want to create and share a different folder than the repository, great, but the DeployStudio Repository should be that, and only that.

> We then tried changing permissions on that Shared Folder as some said it has to be open to everyone, so we set it to read write. 
How exactly did you set it to read/write? Be specific.

> That didn't help, and made the folder into a file in the Finder for some reason, which can not not be accessed even by the admin account that owns it.  Seems Apple is to blame on that one most likely for creating a system that corrupts it's own permissions?

>So, does anyone know the missing info on how a repository is set up, and happen to know how to unscrew Apple's mess of folder permissions to make this work again without rebuilding from scratch?

It doesn't take very long to build from scratch, but I'd unshare the existing repository (in fact, unshare everything), then use the command line to delete the messed up thingee (if necessary).
Create a new folder as described above (after Whoa there...)

You're primary method of managing the OS X server services will be through Server.app. DeployStudio specific configuration is through the DeployStudio Assistant, and the installed DeployStudio system preferences preference pane (for on/off).

The Inappropriate Repository error is typically from using the local file path instead of the server share path is required:
Wrong (using your example above [shudder]) = afp://servername/Macintosh HD/Library/DeployStudio Repository
Right (same example) = afp://servername/DeployStudio Repository

If you put your repository in a folder that is already being shared (not a great idea) then you would have to specify the path from the top level share:
Using your example above (gasp!) = afp://servername/Library/DeployStudio Repository

To simplify things a bit, use a single word for your repository, like DSRepository, or ImageStore or something like that. Spaces aren't forbidden, but need special treatment under certain circumstances, so why complicate things? :)

Oh! And don't confuse the Netboot folder with the DeployStudio Repository.
The Netboot folder is created as a function of turning on the NetInstall service and THAT resides by default (and you shouldn't really ever need to change that) in /Library/
The DeployStudio Repository folder is something you create and share before configuring DeployStudio.

Sorry if some of this is silly, but obviously I'm not a candidate for documentation specialist. :D

Offline

#5 2015-06-15 07:55:45

mjsanders
Member
From: Schiedam, Netherlands
Registered: 2008-09-02
Website

Re: Inappropriate Repository and other missing documentation

The documentation has a relative new 'Quick Install Guide' (http://www.deploystudio.com/get.php?fp=Extras/Quick_Install_Guide.pdf) which covers version 1.6.13
This is better and has more details than the title suggests.
The other document 'DeployStudio Guide 2.0' is rather old indeed, but may contain a few more details (most of them are still relevant)

Offline

#6 2015-06-15 16:30:55

ebonweaver
Member
Registered: 2015-06-09

Re: Inappropriate Repository and other missing documentation

>Whoa there, pardner! Where did you get "/Library/DeployStudio Repository" from?

The install/ setup creates it.  I find it interesting you find this unusual when it's the default.  We went with defaults rather than trying to customize things.
And no, that share, or really this "server", is not used for anything else.

>The Inappropriate Repository error is typically from using the local file path instead of the server share path is required:
>Wrong (using your example above [shudder]) = afp://servername/Macintosh HD/Library/DeployStudio Repository
>Right (same example) = afp://servername/DeployStudio Repository

The default that the client tries to contact from it's default configuration is http://serverfqdn:60080
Again, we went with defaults.  You seem to indicate that we should change this somehow to be using afp by default with a specific path.  However, trying this on the client results in an unreachable host error.
I would add that both afp and http connections from a normal machine on the same subnet work fine.  I can Go->Connect to server to the fqdn with no issue, as well as point Safari to fqdn:60080 and log in and see the "DeployStudioServer registered web services"


>Oh! And don't confuse the Netboot folder with the DeployStudio Repository.

No confusion

>The Netboot folder is created as a function of turning on the NetInstall service and THAT resides by default (and you shouldn't really ever need to change that) in /Library/

Specifically /Library/NetBoot with images in /NetbootSP0 yes

>The DeployStudio Repository folder is something you create and share before configuring DeployStudio.

Incorrect.  This folder is made by the DeployStudio Assistant.  Regardless, while normal machines can reach the repository with no issue, the netbooted client that autostarts the DS Runtime can reach it by http but feels it's inappropriate for some reason.  It can not seem to reach it by afp for unknown reasons, but that's assuming the runtime is trying to talk to it properly by that protocol I guess.


If we were to delete the existing repository and make a new one, what would be the proper steps?  This is one place where the documentation seems to fall short.  The steps as you outline would seem to be:
1. Make a folder somewhere common, like the root of the drive, or maybe /Users ?
2. Share that folder in File Sharing in Server.app, with read for all?
3. Re-run the DS Assistant and for the server address put in... ?? afp://serverfqdn/sharefolder ??
4. Set the repository location to the above folder

Offline

#7 2015-06-15 17:08:27

ebonweaver
Member
Registered: 2015-06-09

Re: Inappropriate Repository and other missing documentation

I should also add that from the netbooted client, the DS Admin can connect to the server just fine (over http, afp seems entirely unused thus far by default...), it's just the Runtime that appears to be broken in thinking the repository is "inappropriate", whatever that's supposed to mean.  Until the Runtime is convinced the repository is valid, DS is not usable, and it gives no indication what it's problem is and there seems to be no logging to help either.

Offline

#8 2015-06-15 17:54:40

Meat
Member
From: SF CA US
Registered: 2009-02-04

Re: Inappropriate Repository and other missing documentation

> ebonweaver wrote:

> The default that the client tries to contact from it's default configuration is http://serverfqdn:60080
> Again, we went with defaults.  You seem to indicate that we should change this somehow to be using afp by default with a specific path.  However, trying this on the client results in an unreachable host error.
> I would add that both afp and http connections from a normal machine on the same subnet work fine.  I can Go->Connect to server to the fqdn with no issue, as well as point Safari > to fqdn:60080 and log in and see the "DeployStudioServer registered web services"

There are two paths you want to be correct on the server side.
1. The Server address: http://serverfqdn:60080 <- Set on both the DeployStudio Server and in the netboot set.
2. The network repository: afp://serverfqdn/sharefolder <- Set on the server.

> If we were to delete the existing repository and make a new one, what would be the proper steps?  This is one place where the documentation seems to fall short.  The steps as you outline would seem to be:
> 1. Make a folder somewhere common, like the root of the drive, or maybe /Users ?
> 2. Share that folder in File Sharing in Server.app, with read for all?
3. Re-run the DS Assistant and for the server address, put in... http://serverfqdn:60080
> 4. Set the repository location to the above folder afp://serverfqdn/sharefolder

That should do it.

Last edited by Meat (2015-06-15 17:56:21)

Offline

#9 2015-06-16 21:36:00

ebonweaver
Member
Registered: 2015-06-09

Re: Inappropriate Repository and other missing documentation

The magic here, to hopefully help others, is that the options are very misleading.  Do NOT tell the server setup that the repository is in a folder.  Rationally you would expect this is the storage location for the server config, and then the client will contact the server and get the info.  Not so.  This tells the client to look at this local path on the client, which of course makes no sense as it would mean your image was stored inside the netboot image.  What you actually need to do is tell the server to find itself by a network path instead, because that is how the client will find it.  You would think telling it the repo is at a network path is only for when it's on another server.  Totally counter to how anything else works, definitely needs clarity.

Offline

#10 2015-06-18 01:28:10

Meat
Member
From: SF CA US
Registered: 2009-02-04

Re: Inappropriate Repository and other missing documentation

None of the following is to suggest you are in any way wrong. Just adding some additional perspective.

Yes. It is a bit confusing, but the DeployStudio Assistant does actually have descriptions of both options in the "Repository type" section of the server setup, which if read very carefully does make sense.
I admit I was bitten by this early in the DeployStudio adoption and configuration here at our office, but...

So, the "local" thing is for use during configuration of DeployStudio on a bootable external drive, with your images on it, that you boot up your target machine from to image it.
It's a nice option for one-off imaging in the field, where accessing a network share would be problematic.

Otherwise, if you manage a file server, then this is a fairly expected requirement.
A "client" wants to get to some files? Don't give them the local path on the server. That won't do them any good. Give them the server share path. Same goes for netboot clients. How will the DeployStudio or netboot clients know which share to access? You provide the DeployStudio server with the share path during configuration, and it then informs the netboot clients.
DeployStudio will not try to intuit what your share path is going to be.

If you are using a server (including the DeployStudio server with a shared repository on it), then use the server share path to the repository.

As you observed, a plus side of this share path being entered in at the server side of things is that if you decide to move your repository to a different server, or an additional drive on that same server, you walk through the DeployStudio Assistant and enter the new share path. You don't have to recreate (which could take an hour or so...) already working netboot sets with the new repository location.

Offline

#11 2015-06-18 03:50:14

ebonweaver
Member
Registered: 2015-06-09

Re: Inappropriate Repository and other missing documentation

>So, the "local" thing is for use during configuration of DeployStudio on a bootable external drive, with your images on it, that you boot up your target machine from to image it.
>It's a nice option for one-off imaging in the field, where accessing a network share would be problematic.

We're having a really hard time understanding why someone would want to run a server on a pocket drive to do a one off restore rather than just applying an image with Disk Utility.

>As you observed, a plus side of this share path being entered in at the server side of things is that if you decide to move your repository to a different server, or an additional drive on that same server, you walk through the DeployStudio Assistant and enter the new share path. You don't have to recreate (which could take an hour or so...) already working netboot sets with the new repository location.

Sorry but that's not true.  In order for the client to find the repository after you change it in the server settings, you have to make a new netboot set with those setting since they are in the netboot image configuration for the DS Runtime.  Unless of course you don't mind manually connecting the Runtime, but that kind of defeats the purpose of the automation.

Offline

#12 2015-06-18 17:55:14

Meat
Member
From: SF CA US
Registered: 2009-02-04

Re: Inappropriate Repository and other missing documentation

> ebonweaver wrote:
>We're having a really hard time understanding why someone would want to run a server on a pocket drive to do a one off restore rather than just applying an image with Disk Utility.

DeployStudio performs a number of tasks, which arguably one could perform via a few extra steps and a scripted solution when just using Disk Utility.
A partial list of things DeployStudio does for example: partitioning, removing network prefs, renaming ByHost files,.. all in a repeatable workflow.

Once familiar with DeployStudio netboot imaging, the same tool (DeployStudio) can be used for one-offs via external drive with the same basic functionality.

> >As you observed, a plus side of this share path being entered in at the server side of things is that if you decide to move your repository to a different server, or an additional drive on that same server, you walk through the DeployStudio Assistant and enter the new share path. You don't have to recreate (which could take an hour or so...) already working netboot sets with the new repository location.

>Sorry but that's not true.  In order for the client to find the repository after you change it in the server settings, you have to make a new netboot set with those setting since they are in the netboot image configuration for the DS Runtime.  Unless of course you don't mind manually connecting the Runtime, but that kind of defeats the purpose of the automation.

The DeployStudio Runtime in the netboot set gets the repository address from the server via the http://serverfqnd:60080 address. You never enter the afp://repository address into the netboot set configuration.
With the same server, and a new repository location with the same file share credentials, I believe this is true.

I'm certainly open to correction, though I performed this very task several months ago, and do not recall having to create new netboot sets.
In fact, because you sounded so certain, I just tested this on a DeployStudio Server.
I created a folder on another of the server's disks, shared it in Server.app, and pointed DeployStudio Server to that new share as the repository.
DeployStudio Server dutifully populated the repository with the default folders, etc.
I netbooted a client and was indeed pointed at the new repository location. No runtime manual connection required.

Now I will point it back at my original repository. :)

Offline

#13 2017-08-11 23:57:01

Jondalf the Grey
Member
From: Windsor, Ontario
Registered: 2017-08-10
Website

Re: Inappropriate Repository and other missing documentation

Thank you Meat, I had to reread the bit about "Don't give them the local path on the server. That won't do them any good. Give them the server share path." but it eventually percolated down through my rusty grey matter and then it was an "OH! NOW I get it." Many thanks, this solved a problem I've been trying to crack for two days.


"Zombies: 100% Post-Consumer Human. Reduce. Reuse. Reanimate." - OotS

Offline

Board footer

Powered by FluxBB