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-30 15:13:20

Nathan Fisher
Member
Registered: 2014-08-13

password-protected publishing override

Another really useful addition would be the ability to enter a password (such as the password used to connect to the repo) to override the workflow publishing restriction.  So if I'm in a lab somewhere and find a machine that needs reimaging, I can netboot it, which will likely load up to DS with NO workflows listed and none auto-starting, enter in a password, and get the FULL list of workflows, select one and kick it off.

The way DS is presently set up, I have to remote into my desktop, open DS, figure out which machine it is and set its default workflow and then reboot the computer, or I can just publish the workflow I need and hope no one else is trying to netboot right now, and again I have to reboot the machine.  If I can't access DS from where I am, my hands are tied and I have to go back to the office.  Just being able to enter a password and GO would be much more convenient.

As it is right now, I have a workaround - I have published "password-protected workflows" that wait for a password to appear in a local file on the computer, hash it, and compare against the hash before continuing, so I start the workflow, open terminal and echo in the password, and that starts the workflow - awkward, but saves me a 20 minute walk and a netboot reboot.  It does this while preventing random users from reimaging their computers to god-knows-what

Here's the password script for those interested.  Just insert this script as the first step in your workflow to protect it, then go ahead and publish it.  I had to tweak it a bit for your use here so it may require very minor debugging if I goofed something up:

If you find this useful please let me know.  I've posted some scripts previously and gotten little or not response, so I wonder if I'm wasting my time by posting this sort of thing here with nobody using it.

#!/bin/bash

app=ds_password
vers=2014.09.12.A

password_file="/var/root/pw"
salt="redbrick"

hashed="faac76cceffd47e82bb8449a02a617fe"  # hashes are case-sensitive!
# to generate $hashed for the password "golfball" using the salt "redbrick",  echo "redbrickgolfball" | openssl md5
# this prevents the password from being visible in the publicly accessible workflow
# and also prevents the hash from matching any other hash

echo "Requiring password to proceed"

echo "Echo password into $password_file now ($$): "
echo
echo

while true ; do
  while ! [ -f "$password_file" ] ; do
    test
  done
  p=
  p=$(cat "$password_file")
  p=$(echo "${salt}${p}" | openssl md5)
  echo "hashed password found: $p"
  rm "$password_file"
  if [ "$p" == "$hashed" ] ; then
    break
  else
    echo
    echo "password incorrect, try again."
    echo
  fi
done

echo "Password accepted, proceeding with workflow..."

Offline

#2 2015-06-30 17:36:18

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

Re: password-protected publishing override

I thought that was sorta built in?

Offline

#3 2015-06-30 17:49:14

Nathan Fisher
Member
Registered: 2014-08-13

Re: password-protected publishing override

could be!  If it is, I haven't found it yet.  I just started using this last year so I wouldn't be surprised to find out new things.  As far as I can tell, there is no way to assign a password to a workflow, and if you mark it as published it shows up and if not it does not.  There appears to be no way to protect a workflow from being used while being convenient to access when needed. (nor any option for protected access to unpublished workflows)  If you know of a way, I'd love to hear it - it may be old news to you but it'd be new to me.

Offline

#4 2015-06-30 19:09:50

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

Re: password-protected publishing override

Seems like it's an option when access groups have been configured in step #8 of the DeployStudio Assistant's server configuration.
"The Runtime application supports multiple groups (press return to validate each group). You'll be able to limit the usage of your workflows and/or disk images to one of these groups."

If you have multiple groups configured in the DS Runtime: field, can you select a specific group at the workflow level?

I've never done this, because our DeployStudio servers are only available on a couple of ITS subnets, but it seems to suggest that might be the case?

Offline

#5 2015-06-30 19:47:32

Nathan Fisher
Member
Registered: 2014-08-13

Re: password-protected publishing override

I did notice group setup but never went that route.  Looking at it now, it says the runtime supports multiple groups.  I just added a group to the server and put that in as the runtime group.  that immediately locked me and my boot image out of the runtime, so I added my usual admin user into that group and that lets me back in.  However, it doesn't appear to have added any new options for workflows.  When I edit a workflow, there is no option there to select which groups have access to it.  In the setup I can change which groups have access to ALL of the workflows in the runtime by preventing them from logging into the ds server via the runtime, but I think that's it?  Am I missing something?

also, I see no way to change whom I am logged in as under the runtime.  So if a computer net boots, it will automatically login as whomever I've set up in the boot image, and I cannot change that after it boots up?  So there's no point to restricting which account can access a given workflow, if I have no way to change accounts while I am in the lab?  I can't password protect netbooting from a specific image that I know of either.

Offline

#6 2015-06-30 20:02:31

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

Re: password-protected publishing override

If your netboot set does not specify a login account, you would be prompted for login credentials.
Other than that, I have no working knowledge of granting the access you are looking for. :P

It seems like this should be possible, with an array in the plist/s for the workflows. Hmmmm.

The forum admin might have more info on this, I hope, or perhaps a more knowledgeable DeployStudio power user?

Offline

#7 2015-06-30 20:06:53

Nathan Fisher
Member
Registered: 2014-08-13

Re: password-protected publishing override

yep if I don't enter a valid login it will prompt for it, but then it won't work automatically when I try to reimage a lab etc.  hmmm...  maybe if I make a second runtime boot image with no login, and leave the restricted one as the default... no that won't work either unless I can specify WHICH users are allowed to access a given workflow.  It looks like it's an all-or-nothing affair though?  Looks like my script stays in play for awhile. ;)

I would like to make it slightly friendlier to use than it is though.  As it is now, after you select the restricted workflow, you have to open terminal and echo the password into a file, and then it takes off.  That's not too bad as long as you don't have someone hanging over your shoulder. (students)   I wasn't able to find a way to get user-interaction within the script though, they don't accept input from STDIN.  I suppose I can add a script on the runtime image that has just

read -p "Enter password now: " -s pw ; echo "$pw" > "$password_file"

but it'd be nice if DS would just take care of this for me :P

aha, I found a bit of it.  "Access Groups" column in the list of images.  But it doesn't list anything.  I only have one group set up for the runtime though which may be the reason for that.  Now that I'm running an image creation I see my runtime group listed in the "Access Group" field while its creating the image.  Still not too helpful though if I can't change my authentication when the runtime comes up.

Last edited by Nathan Fisher (2015-06-30 20:59:56)

Offline

Board footer

Powered by FluxBB