##osx-server

morgsdaly: as far as i can remember (from wrangling kerberos ages ago)

mosen: there is a mention in the logs of time sync, pretty sure DNS is working as far as my tests go. I will need to school up on Service Principles. Have also been having a PM Enrolment issue on this same server which I think is related to it all.

mosen: I am guessing this is not good? "kinit: krb5_get_init_creds: unable to reach any KDC in realm server.internal.mic, tried 0 KDCs"

heh mosen

whoah net fart

suddenly a whole screen of text scroll

ctdawe: yeah we did

holy buffer explosion

morgsdaly: doesnt seem very good

:)

morgsdaly: but I thought that server still offerred a fallback to NTLM or something basic if kerberos failed, and you're saying that it only stops sharing after 24 hours?

I was talking about a different server yesterday that seems to be slowing after 24 hours... my colleague has that straw today. I started investigating this server because PM enrolment was failing and then this morning after a restart and PM working users cannot SMB.

oh right

server.app hero of the universe

morgsdaly: the fact that AFP works and SMB doesn't might be a clue

mosen: indeed

morgsdaly: because AFP should be preferring kerberos too

a clue that Apple needs to let it go or get it right maybe

yeah I gave up on Server

morgsdaly So long as they need a reference release of Profile Manager, there will be an OS X Server. What puzzles me is the erratic introduction of new services like Xcode Server.

morgsdaly: kdc realm server.internal.nic ?

.mic

checking now loceee

morgsdaly: but i see dns name micserver1.city.internal.mic

I was trying to obscure a little, can't trick you though :)

kinit username@micserver1.city.internal.mic

ha

re DM

mosen what?

you said that yesterday

I'm not all down with the chatroom lingo

welcome back

:)

Thanks heaps mosen & loceee_ for your help.

sorry im a bit hazy morgs

hiya franton

kill ... me ...

okey dokey

*stab*

long long day yesterday

didn't help I wrote this before bed. http://www.richard-purves.com/?p=35

so i guess you got the FV2 restart sorted

yeah

gneagle wrote some code into the pkg that createosxinstallpkg creates

checks for various things

what he didn't do, was log any of the errors so there's no way to tell what failed unless you manually extract out the post install script from the pkg and run it manually

so all I had was a general installer "package install failed. error code 1"

ah well. it's sorted now

ah right

bye all

franton: I have a suggestion for your script - I’d randomise the admin password and then use your management tool to correct it on next boot, so then you don’t have your admin password in the clear anywhere in Munki

Hi

grahamgilbert: good idea. however i'm only presenting it as a proof of concept

any suggestions as to how? (i've got the CEO's laptop heading my way so i'm dropping everything for that today)

Something like dscl . passwd /Users/administrator someRandomStringFromSomewhere

then I’d use puppet to correct the password

I have no puppet

I have munki and deploy studio :(

I don’t have any server infrastructure for puppet

it’s run locally

but you could achieve the same thing with checking password hash - puppet is just wrapping shell scripts

I leave here in just over a week. That's something I don't have the time to do

franton: not with that attitude.

:P

macmule: i'm already working the fucking weekend

macmule: on a pilot to strip out centrify and replicate everything it does manually

and right now i'm wondering why whomever set this up has config profiles to do somethings, and scripts that partly replicate what the profiles do

I think I need a t-shirt that says “Read the Readme"

Said it four times already this morning

grahamgilbert: read the "fine" manual ;)

grahamgilbert: or read the "fabulous" manual :D

yeah

You would think none of our code was in GitHub with a readme for running everything

franton: sounds like my build, I mix and match everything :)

Only if "fabulous" is in sequins