[ https://issues.apache.org/jira/browse/VCL-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15735711#comment-15735711
]
ASF subversion and git services commented on VCL-1003:
------------------------------------------------------
Commit 1773427 from [~jfthomps] in branch 'vcl/trunk'
[ https://svn.apache.org/r1773427 ]
VCL-1003 - drag and drop support for moving privilege nodes
privilege.php:
-modified viewNodes:
-added global javascript variable nodedropdata
-added continuation to update nodedropdata
-added javascript connection for onSet on nodestore
-added ForestStoreModel between store and tree
-added a bunch of javascript connections to tree
-added Undo Move button at bottom of tree
-changed text written vertically for user, user group, and resource groups to be done via
css instead of generating images
-added move confirmation dialog
-added revert move confirmation dialog
-modified selectNode:
-added Undo Move button at bottom of tree
-changed text written vertically for user, user group, and resource groups to be done via
css instead of generating images
-added javascript to set undo button to be enabled if a move can be undone
-modified JSONprivnodelist2: added parent data to each node
-added nodeDropData
-added AJrefreshNodeDropData
-modified AJsubmitAddChildNode: added $parent as argument to addChildNode
-added AJmoveNode
-added AJsubmitMoveNode
-added AJrevertMoveNode
-modified AJchangeUserPrivs: check if user being modified is logged in user and if nodeAdmin,
block, or cascade is being changed, if so, include refreshNodeDropData() in returned javascript
-modified AJchangeUserGroupPrivs: check if user group being modified is one logged in user
is a member of and if nodeAdmin, block, or cascade is being changed, if so, include refreshNodeDropData()
in returned javascript
-modified AJsubmitAddUserPriv: check if submitted user is logged in user and if nodeAdmin,
block, or cascade is being added, if so, include refreshNodeDropData() in returned javascript
-modified AJsubmitAddUserGroupPriv: check if user group being added is one logged in user
is a member of and if nodeAdmin, block, or cascade is being added, if so, include refreshNodeDropData()
in returned javascript
utils.php:
-removed getImageText
-modified getDojoHTML: added dijit.tree.ForestStoreModel and dijit.tree.dndSource to $dojoRequires
for viewNodes; added javascript for dojo.connect for onmouseup to document under case 'viewNodes'
states.php:
-added AJmoveNode
-added AJsubmitMoveNode
-added AJrevertMoveNode
-added AJrefreshNodeDropData
vcl.css:
-added th.privheader
-added th.privheader > div
privilege.js:
-added several globals: saveMoveNode, moveitem, nomove, dragnode, mouseontree, dragging, moveData
object
-general changes in several functions:
-removed some old commented out code
-reworked how selected node is being displayed as selected, previously this was done by
adding and removing the privtreeselected class; now using tree.attr('path') to set and get
the selected node (this is the more proper way)
-changed references to tree.store to refer to tree.model.store since the ForestStoreModel
was added between them
-added mouseDown
-added mouseRelease
-modified addChildNode: added parentid as an additional argument; include parentid when calling
store.newItem; added call to positionNode so that node gets put in the right sort order in
the tree; add an entry to nodedropdata for the new node
-added positionNode
-modified removeNodesFromTree: added code to set the Undo Move button to disabled if the previous
parent of the moved node is the one being removed
-modified removeNodesFromTreeCB: wrapped call to deleteItem with setting nomove to 1 and back
to 0 so that moveNode just returns when invoked by the call to deleteItem
-modified renameNode: added code to put focus on submitRenameNodeBtn, if enter was used to
submit the new name while the focus was on the text box, the new value of the text box was
not saved in the widget and the old name was getting submitted; set focus back on text box
if the name wasn't actually changed in the text box
-modified renameNodeCB: wrapped setValue with setting nomove to 0 and back to 1 so moveNode
just returns when invoked by the call to setValue; added setTimeout to reposition node based
on new name after half a second
-added moveNode
-added moveNodeCB
-added submitMoveNode
-added submitMoveNodeCB
-added submitRevertMoveNode
-added submitRevertMoveNodeCB
-added revertNodeMove
-added revertNodeMoveCB
-added setSelected
-added checkCanMove
-added checkNodeDrop
-added refreshNodeDropData
deleted images/textimage.php - changed code calling this to use css to write text vertically
> drag and drop support for moving privilege nodes
> ------------------------------------------------
>
> Key: VCL-1003
> URL: https://issues.apache.org/jira/browse/VCL-1003
> Project: VCL
> Issue Type: New Feature
> Components: web gui (frontend)
> Reporter: Josh Thompson
>
> Being able to drag and drop privilege nodes to reorganize things would be helpful. Drag
and drop is supported by the Dijit tree widget being used for the privilege tree. So, the
proper hooks just need to be added with supporting php functions to update the database.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Josh Thompson created VCL-1005:
----------------------------------
Summary: allow dashes in image names
Key: VCL-1005
URL: https://issues.apache.org/jira/browse/VCL-1005
Project: VCL
Issue Type: Improvement
Components: web gui (frontend)
Reporter: Josh Thompson
Fix For: 2.5
It would be nice for image names to be able to contain dashes. They were not allowed originally
because the file names derived from the image names were delimited by dashes. That has changed
on the backend so that it doesn't matter if image names contain dashes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Josh Thompson created VCL-1003:
----------------------------------
Summary: drag and drop support for moving privilege nodes
Key: VCL-1003
URL: https://issues.apache.org/jira/browse/VCL-1003
Project: VCL
Issue Type: New Feature
Components: web gui (frontend)
Reporter: Josh Thompson
Being able to drag and drop privilege nodes to reorganize things would be helpful. Drag and
drop is supported by the Dijit tree widget being used for the privilege tree. So, the proper
hooks just need to be added with supporting php functions to update the database.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Henry,
I've been thinking the same thing. I'll make the change.
Josh
On Sunday, November 13, 2016 12:46:06 PM Henry Schaffer wrote:
> I've recently had to track a user's usage and so I've been using
> Manage -> User Lookup
>
> Wouldn't it make more sense to have this under the Reporting tab, rather
> than the Manage tab?
>
> --henry schaffer
- --
- -------------------------------
Josh Thompson
VCL Developer
North Carolina State University
my GPG/PGP key can be found at pgp.mit.edu
All electronic mail messages in connection with State business which
are sent to or received by this account are subject to the NC Public
Records Law and may be disclosed to third parties.
-----BEGIN PGP SIGNATURE-----
iEYEARECAAYFAlgp5oEACgkQV/LQcNdtPQP7HgCeIfE2rbB0lYmS++egUUKS68ej
HMAAnjxb8sfurYqgOy33AeHzWi8vkY36
=sTz7
-----END PGP SIGNATURE-----

I've recently had to track a user's usage and so I've been using
Manage -> User Lookup
Wouldn't it make more sense to have this under the Reporting tab, rather
than the Manage tab?
--henry schaffer

[jira] [Created] (VCL-1002) Reinstall option does not ask if you'd like to install newer production revision"Andy Kurth (JIRA)" <jira@apache.org>urn:uuid:%3cJIRA-13020181-1478892856000-256845-1478892898320@Atlassian-JIRA%3e2016-11-11T19:34:58Z

Andy Kurth created VCL-1002:
-------------------------------
Summary: Reinstall option does not ask if you'd like to install newer production
revision
Key: VCL-1002
URL: https://issues.apache.org/jira/browse/VCL-1002
Project: VCL
Issue Type: Improvement
Components: web gui (frontend)
Reporter: Andy Kurth
I came across a situation where an image revision had been updated with important changes
and a user had a reservation for an older revision of that image. I was hoping that the user
could use the Reinstall option to reload the comptuer with the newer, production revision.
This is not possible AFAIK. When the user attempts to reinstall, it only reinstalls the revision
originally set for the reservation. No revision selection pop-ups are displayed.
It might be useful to display a revision selection pop-up when the reinstall option is used
and the original reservation image revision is not the current production revision.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[ https://issues.apache.org/jira/browse/VCL-1001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Thompson resolved VCL-1001.
--------------------------------
Resolution: Fixed
I can't believe I just recently discovered this. It is a bug in code that is run every time
a user updates a reservation and it has been there for at least 8 years.
> changing a future reservation to a now reservation doesn't properly update the reserved
computer
> ------------------------------------------------------------------------------------------------
>
> Key: VCL-1001
> URL: https://issues.apache.org/jira/browse/VCL-1001
> Project: VCL
> Issue Type: Bug
> Components: web gui (frontend)
> Reporter: Josh Thompson
> Fix For: 2.5
>
>
> If a user has a reservation for a computer that is in the future and then changes the
reservation so that the start time is in the past, making it a "now" reservation, the code
that updates which computer is assigned to the user gets skipped. Fortunately, the backend
catches that the computer is inuse and fails the reservation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[ https://issues.apache.org/jira/browse/VCL-1001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15634034#comment-15634034
]
ASF subversion and git services commented on VCL-1001:
------------------------------------------------------
Commit 1767960 from [~jfthomps] in branch 'vcl/trunk'
[ https://svn.apache.org/r1767960 ]
VCL-1001 - changing a future reservation to a now reservation doesn't properly update the
reserved computer
requests.php: modified AJsubmitEditRequest: added code to determine if old start time was
in the future or not and pass 'now' or 'future' to updateRequest accordingly
utils.php: modified updateRequest: added additional argument $nowfuture and removed code that
determined if the reservation was now or future based on the reservation start time - the
problem was that if a future reservation got changed to a now reservation, the isAvailable
could have changed the computerid, but nowfuture was determined to be now and then the 2nd
half of the function where the computerid is updated was skipped; so the user ended up with
a reservation on the same computer they had, which may or may not have another reservation
on it
xmlrpcWrappers.php: updated XMLRPCextendRequest and XMLRPCsetRequestEnding: added 'now' to
call to updateRequest
> changing a future reservation to a now reservation doesn't properly update the reserved
computer
> ------------------------------------------------------------------------------------------------
>
> Key: VCL-1001
> URL: https://issues.apache.org/jira/browse/VCL-1001
> Project: VCL
> Issue Type: Bug
> Components: web gui (frontend)
> Reporter: Josh Thompson
> Fix For: 2.5
>
>
> If a user has a reservation for a computer that is in the future and then changes the
reservation so that the start time is in the past, making it a "now" reservation, the code
that updates which computer is assigned to the user gets skipped. Fortunately, the backend
catches that the computer is inuse and fails the reservation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Josh Thompson created VCL-1001:
----------------------------------
Summary: changing a future reservation to a now reservation doesn't properly
update the reserved computer
Key: VCL-1001
URL: https://issues.apache.org/jira/browse/VCL-1001
Project: VCL
Issue Type: Bug
Components: web gui (frontend)
Reporter: Josh Thompson
Fix For: 2.5
If a user has a reservation for a computer that is in the future and then changes the reservation
so that the start time is in the past, making it a "now" reservation, the code that updates
which computer is assigned to the user gets skipped. Fortunately, the backend catches that
the computer is inuse and fails the reservation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (VCL-1000) Run custom scripts at various stages on the management node"ASF subversion and git services (JIRA)" <jira@apache.org>urn:uuid:%3cJIRA-13016714-1477943700000-147143-1478026198504@Atlassian-JIRA%3e2016-11-01T18:49:58Z

[ https://issues.apache.org/jira/browse/VCL-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15626308#comment-15626308
]
ASF subversion and git services commented on VCL-1000:
------------------------------------------------------
Commit 1767546 from arkurth@apache.org in branch 'vcl/trunk'
[ https://svn.apache.org/r1767546 ]
VCL-1000
Added post_reserve and post_reservation hooks to Linux.pm.
> Run custom scripts at various stages on the management node
> -----------------------------------------------------------
>
> Key: VCL-1000
> URL: https://issues.apache.org/jira/browse/VCL-1000
> Project: VCL
> Issue Type: New Feature
> Components: vcld (backend)
> Reporter: Andy Kurth
> Assignee: Andy Kurth
>
> There are cases where it would be useful to be able to have scripts executed on the management
at various stages of reservations. For example, a script could be executed to configure an
external firewall or provision storage when a computer is reserved. Whatever was configured
specifically for the reservation could be reverted when the reservation ends by another script.
> We already have this functionality for scripts that get executed on the computer ([VCL-564|https://issues.apache.org/jira/browse/VCL-564]).
However, there are situations where you would need to perform actions from the management
node.
> The script would need access to information about the reservation. Since it resides and
is executed on the management node, the script could call mysql to query the database. This
isn't the safest way of handling things.
> Another option could be to create a text file on the management node prior to executing
the script(s). The script could parse the text file to extract the information it requires.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (VCL-1000) Run custom scripts at various stages on the management node"Andy Kurth (JIRA)" <jira@apache.org>urn:uuid:%3cJIRA-13016714-1477943700000-144714-1478012999016@Atlassian-JIRA%3e2016-11-01T15:09:59Z

[ https://issues.apache.org/jira/browse/VCL-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15625662#comment-15625662
]
Andy Kurth commented on VCL-1000:
---------------------------------
I wrote most of the code for this and currently only have hooks for pre_capture and post_capture.
This scripts are only executed if the variable table contains a _enable\_experimental\_features_
entry whose value is true.
Some things need to be decided before this can be fully implemented. First, the location
of the script files. There is a class variable in OS.pm named $MN_STAGE_SCRIPTS_DIRECTORY
that determines this. It is currently set to */usr/local/vcl/tools/mn_stage_scripts*. I'm
not sure if I like this location very much.
We have a large number of directories for each OS under tools. Under each there is a *Scripts*
subdirectory. This is where scripts may be stored which get executed on the computers at
the various stages. It's necessary to have a lot of control over which scripts run for each
OS when they are run on the loaded computers. It isn't much of an issue for scripts that
run on the managment node.
We could either use the tools/<OS>/Scripts structure for scripts that get executed on
the management node or use an entirely different location.
If we use the same location for both, we'll need to figure out how to differentiate scripts
intended to be run on computers vs. run on the management node. I don't want to have to add
additional directories under each OS for each stage. There are already dozens of them.
We could define a naming convention for the scripts such as anything beginning with *mn_*
runs on the management node, everything else on the computer.
> Run custom scripts at various stages on the management node
> -----------------------------------------------------------
>
> Key: VCL-1000
> URL: https://issues.apache.org/jira/browse/VCL-1000
> Project: VCL
> Issue Type: New Feature
> Components: vcld (backend)
> Reporter: Andy Kurth
> Assignee: Andy Kurth
>
> There are cases where it would be useful to be able to have scripts executed on the management
at various stages of reservations. For example, a script could be executed to configure an
external firewall or provision storage when a computer is reserved. Whatever was configured
specifically for the reservation could be reverted when the reservation ends by another script.
> We already have this functionality for scripts that get executed on the computer ([VCL-564|https://issues.apache.org/jira/browse/VCL-564]).
However, there are situations where you would need to perform actions from the management
node.
> The script would need access to information about the reservation. Since it resides and
is executed on the management node, the script could call mysql to query the database. This
isn't the safest way of handling things.
> Another option could be to create a text file on the management node prior to executing
the script(s). The script could parse the text file to extract the information it requires.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (VCL-1000) Run custom scripts at various stages on the management node"ASF subversion and git services (JIRA)" <jira@apache.org>urn:uuid:%3cJIRA-13016714-1477943700000-144314-1478010238467@Atlassian-JIRA%3e2016-11-01T14:23:58Z

[ https://issues.apache.org/jira/browse/VCL-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15625553#comment-15625553
]
ASF subversion and git services commented on VCL-1000:
------------------------------------------------------
Commit 1767501 from arkurth@apache.org in branch 'vcl/trunk'
[ https://svn.apache.org/r1767501 ]
VCL-1000
Forgot to save this minor addition before last commit: In OS.pm::pre_capture, only gets executed
if a 'enable_experimental_features' variable is true in the database.
> Run custom scripts at various stages on the management node
> -----------------------------------------------------------
>
> Key: VCL-1000
> URL: https://issues.apache.org/jira/browse/VCL-1000
> Project: VCL
> Issue Type: New Feature
> Components: vcld (backend)
> Reporter: Andy Kurth
> Assignee: Andy Kurth
>
> There are cases where it would be useful to be able to have scripts executed on the management
at various stages of reservations. For example, a script could be executed to configure an
external firewall or provision storage when a computer is reserved. Whatever was configured
specifically for the reservation could be reverted when the reservation ends by another script.
> We already have this functionality for scripts that get executed on the computer ([VCL-564|https://issues.apache.org/jira/browse/VCL-564]).
However, there are situations where you would need to perform actions from the management
node.
> The script would need access to information about the reservation. Since it resides and
is executed on the management node, the script could call mysql to query the database. This
isn't the safest way of handling things.
> Another option could be to create a text file on the management node prior to executing
the script(s). The script could parse the text file to extract the information it requires.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (VCL-1000) Run custom scripts at various stages on the management node"ASF subversion and git services (JIRA)" <jira@apache.org>urn:uuid:%3cJIRA-13016714-1477943700000-144292-1478010058627@Atlassian-JIRA%3e2016-11-01T14:20:58Z

[ https://issues.apache.org/jira/browse/VCL-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15625544#comment-15625544
]
ASF subversion and git services commented on VCL-1000:
------------------------------------------------------
Commit 1767498 from arkurth@apache.org in branch 'vcl/trunk'
[ https://svn.apache.org/r1767498 ]
VCL-1000
Added to OS.pm:
* create_management_node_reservation_info_json_file
* delete_management_node_reservation_info_json_file
* get_management_node_reservation_info_json_file_path
* post_capture
* run_management_node_stage_scripts
Added call to run_management_node_stage_scripts in OS.pm::pre_capture. It only gets executed
if a 'enable_experimental_features' variable is true in the database.
Added call to post_capture at the end of image.pm::process. It calls run_management_node_stage_scripts
which also only gets executed if a 'enable_experimental_features' variable is true in the
database.
> Run custom scripts at various stages on the management node
> -----------------------------------------------------------
>
> Key: VCL-1000
> URL: https://issues.apache.org/jira/browse/VCL-1000
> Project: VCL
> Issue Type: New Feature
> Components: vcld (backend)
> Reporter: Andy Kurth
> Assignee: Andy Kurth
>
> There are cases where it would be useful to be able to have scripts executed on the management
at various stages of reservations. For example, a script could be executed to configure an
external firewall or provision storage when a computer is reserved. Whatever was configured
specifically for the reservation could be reverted when the reservation ends by another script.
> We already have this functionality for scripts that get executed on the computer ([VCL-564|https://issues.apache.org/jira/browse/VCL-564]).
However, there are situations where you would need to perform actions from the management
node.
> The script would need access to information about the reservation. Since it resides and
is executed on the management node, the script could call mysql to query the database. This
isn't the safest way of handling things.
> Another option could be to create a text file on the management node prior to executing
the script(s). The script could parse the text file to extract the information it requires.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (VCL-1000) Run custom scripts at various stages on the management node"Andy Kurth (JIRA)" <jira@apache.org>urn:uuid:%3cJIRA-13016714-1477943700000-136112-1477943939542@Atlassian-JIRA%3e2016-10-31T19:58:59Z

[ https://issues.apache.org/jira/browse/VCL-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Kurth updated VCL-1000:
----------------------------
Description:
There are cases where it would be useful to be able to have scripts executed on the management
at various stages of reservations. For example, a script could be executed to configure an
external firewall or provision storage when a computer is reserved. Whatever was configured
specifically for the reservation could be reverted when the reservation ends by another script.
We already have this functionality for scripts that get executed on the computer ([VCL-564|https://issues.apache.org/jira/browse/VCL-564]).
However, there are situations where you would need to perform actions from the management
node.
The script would need access to information about the reservation. Since it resides and is
executed on the management node, the script could call mysql to query the database. This isn't
the safest way of handling things.
Another option could be to create a text file on the management node prior to executing the
script(s). The script could parse the text file to extract the information it requires.
was:
There are cases where it would be useful to be able to have scripts executed on the management
at various stages of reservations. For example, a script could be executed to configure an
external firewall or provision storage when a computer is reserved. Whatever was configured
specifically for the reservation could be reverted when the reservation ends by another script.
We already have this functionality for scripts that get executed on the computer ([VCL-564|https://issues.apache.org/jira/browse/VCL-564]).
The script would need access to information about the reservation. Since it resides and is
executed on the management node, the script could call mysql to query the database. This isn't
the safest way of handling things.
Another option could be to create a text file on the management node prior to executing the
script(s). The script could parse the text file to extract the information it requires.
> Run custom scripts at various stages on the management node
> -----------------------------------------------------------
>
> Key: VCL-1000
> URL: https://issues.apache.org/jira/browse/VCL-1000
> Project: VCL
> Issue Type: New Feature
> Components: vcld (backend)
> Reporter: Andy Kurth
> Assignee: Andy Kurth
>
> There are cases where it would be useful to be able to have scripts executed on the management
at various stages of reservations. For example, a script could be executed to configure an
external firewall or provision storage when a computer is reserved. Whatever was configured
specifically for the reservation could be reverted when the reservation ends by another script.
> We already have this functionality for scripts that get executed on the computer ([VCL-564|https://issues.apache.org/jira/browse/VCL-564]).
However, there are situations where you would need to perform actions from the management
node.
> The script would need access to information about the reservation. Since it resides and
is executed on the management node, the script could call mysql to query the database. This
isn't the safest way of handling things.
> Another option could be to create a text file on the management node prior to executing
the script(s). The script could parse the text file to extract the information it requires.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (VCL-1000) Run custom scripts at various stages on the management node"Andy Kurth (JIRA)" <jira@apache.org>urn:uuid:%3cJIRA-13016714-1477943700000-136111-1477943878312@Atlassian-JIRA%3e2016-10-31T19:57:58Z

[ https://issues.apache.org/jira/browse/VCL-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Kurth updated VCL-1000:
----------------------------
Description:
There are cases where it would be useful to be able to have scripts executed on the management
at various stages of reservations. For example, a script could be executed to configure an
external firewall or provision storage when a computer is reserved. Whatever was configured
specifically for the reservation could be reverted when the reservation ends by another script.
We already have this functionality for scripts that get executed on the computer ([VCL-564|https://issues.apache.org/jira/browse/VCL-564]).
The script would need access to information about the reservation. Since it resides and is
executed on the management node, the script could call mysql to query the database. This isn't
the safest way of handling things.
Another option could be to create a text file on the management node prior to executing the
script(s). The script could parse the text file to extract the information it requires.
was:
There are cases where it would be useful to be able to have scripts executed on the management
at various stages of reservations. For example, a script could be executed to configure an
external firewall or provision storage when a computer is reserved. Whatever was configured
specifically for the reservation could be reverted when the reservation ends by another script.
The script would need access to information about the reservation. Since it resides and is
executed on the management node, the script could call mysql to query the database. This isn't
the safest way of handling things.
Another option could be to create a text file on the management node prior to executing the
script(s). The script could parse the text file to extract the information it requires.
> Run custom scripts at various stages on the management node
> -----------------------------------------------------------
>
> Key: VCL-1000
> URL: https://issues.apache.org/jira/browse/VCL-1000
> Project: VCL
> Issue Type: New Feature
> Components: vcld (backend)
> Reporter: Andy Kurth
> Assignee: Andy Kurth
>
> There are cases where it would be useful to be able to have scripts executed on the management
at various stages of reservations. For example, a script could be executed to configure an
external firewall or provision storage when a computer is reserved. Whatever was configured
specifically for the reservation could be reverted when the reservation ends by another script.
> We already have this functionality for scripts that get executed on the computer ([VCL-564|https://issues.apache.org/jira/browse/VCL-564]).
> The script would need access to information about the reservation. Since it resides and
is executed on the management node, the script could call mysql to query the database. This
isn't the safest way of handling things.
> Another option could be to create a text file on the management node prior to executing
the script(s). The script could parse the text file to extract the information it requires.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (VCL-1000) Run custom scripts at various stages on the management node"Andy Kurth (JIRA)" <jira@apache.org>urn:uuid:%3cJIRA-13016714-1477943700000-136108-1477943758327@Atlassian-JIRA%3e2016-10-31T19:55:58Z

Andy Kurth created VCL-1000:
-------------------------------
Summary: Run custom scripts at various stages on the management node
Key: VCL-1000
URL: https://issues.apache.org/jira/browse/VCL-1000
Project: VCL
Issue Type: New Feature
Components: vcld (backend)
Reporter: Andy Kurth
Assignee: Andy Kurth
There are cases where it would be useful to be able to have scripts executed on the management
at various stages of reservations. For example, a script could be executed to configure an
external firewall or provision storage when a computer is reserved. Whatever was configured
specifically for the reservation could be reverted when the reservation ends by another script.
The script would need access to information about the reservation. Since it resides and is
executed on the management node, the script could call mysql to query the database. This isn't
the safest way of handling things.
Another option could be to create a text file on the management node prior to executing the
script(s). The script could parse the text file to extract the information it requires.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[ https://issues.apache.org/jira/browse/VCL-995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15615822#comment-15615822
]
ASF subversion and git services commented on VCL-995:
-----------------------------------------------------
Commit 1767037 from [~jfthomps] in branch 'vcl/trunk'
[ https://svn.apache.org/r1767037 ]
VCL-995 - Unable to change server reservation name if schedule no longer available
requests.php:
-modified viewRequests: added additional status message div (editResDlgPartialMsg) to editResDlg
for displaying when some items were successfully updated but there were errors with other
items
-modified AJeditRequest: added "No change" option to duration change dropdown so that other
items can be changed without submitting an extension to the reservation; needed to modify
places that check for $lengths not being empty since it now contained a "No check" option
in some cases
-modified AJsubmitEditRequest: moved where server request related items and nousercheck are
updated in database to before isAvailable is called; if isAvailable does not return positive
number and other items were already updated, send additional message (partialupdate) to notify
user that parts were successfully updated
> Unable to change server reservation name if schedule no longer available
> ------------------------------------------------------------------------
>
> Key: VCL-995
> URL: https://issues.apache.org/jira/browse/VCL-995
> Project: VCL
> Issue Type: Bug
> Components: web gui (frontend)
> Affects Versions: 2.4.2
> Reporter: Andy Kurth
> Fix For: 2.5
>
>
> Scenario:
> * Have existing _Indefinite Ending_ server reservation
> * When it was made, there were other future reservations assigned to the computer and
no schedule restrictions
> * After reservation was made, computer schedule changed so that _Indefinite Ending_ is
no longer allowed
> * Click *More Options* > *Edit*
> * Change the name, leave _Indefinite Ending_ selected, click *Modify Reservation*
> This is not allowed. Message appears:
> {panel}
> The time period you have requested is not available.
> Please select a different time.
> {panel}
> The ability to rename a reservation should not depend on the end time. Perhaps we could
split these into separate *More Options* options?
> * Edit Reservation Name
> * Edit Reservation Groups
> * Edit Reservation End Time
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (VCL-862) Tag loaded image when request is reserved, inuse, or modified in any way other than a normal reload"ASF subversion and git services (JIRA)" <jira@apache.org>urn:uuid:%3cJIRA-12820834-1429023025000-93286-1477514158519@Atlassian-JIRA%3e2016-10-26T20:35:58Z

[ https://issues.apache.org/jira/browse/VCL-862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15609594#comment-15609594
]
ASF subversion and git services commented on VCL-862:
-----------------------------------------------------
Commit 1766734 from arkurth@apache.org in branch 'vcl/trunk'
[ https://svn.apache.org/r1766734 ]
VCL-862
Updated OS.pm::set_tainted_status to accept a $reason argument. This gets added to currentimage.txt
instead of simply 'true'. Updated sub to append to previous 'vcld_tainted' messages instead
of overwriting.
> Tag loaded image when request is reserved, inuse, or modified in any way other than a
normal reload
> ---------------------------------------------------------------------------------------------------
>
> Key: VCL-862
> URL: https://issues.apache.org/jira/browse/VCL-862
> Project: VCL
> Issue Type: Improvement
> Components: vcld (backend)
> Reporter: Andy Kurth
> Assignee: Andy Kurth
> Fix For: 2.5
>
>
> It would be beneficial to tag the OS of a loaded computer once a request enters the reserved
or inuse states. It would also be beneficial to tag a computer if anything is done to the
computer which would not be done for a normal, non-cluster reservation. By tagging, I mean
add something withing the computer's OS indicating the state. The easiest way to do this
would be to add text to the _currentimage.txt_ file. We currently do this after the OS module's
_post_load_ subroutine has run.
> The benefits would pertain to security and a consistent user experience. If for some
reason, a computer gets put back into the _available_ state that had previously been reserved
for a user but not fully sanitized or if the user logged in, the computer should be reloaded
before being reserved for another user. This ordinarily wouldn't happen but is possible if
one of the vcld processes abruptly dies or if the database is manipulated.
> Once a computer is reserved for a user, a line should be added to _currentimage.txt_.
It could simply be a timestamp and the word _reserved_. If the computer is sanitized due
to the user not acknowledging or connecting, the user accounts should be removed. Once completely
sanitized, the line should be removed. If for any reason the computer isn't completely sanitized,
the line would remain. Future reservation processes would see this and reload the computer.
> The same would be true if the user connects. An _inuse_ line would be added to _currentimage.txt_.
> The code should also check if anything alters the computer which would not ordinarily
happen for a single-computer reservation such as cluster scripts being run. For example,
an image could be a child image for a cluster. A user could make a reservation for the cluster
image and something could be applied to the to the child computer. If the user never acknowledges,
the child computer wouldn't be reloaded. It could be assigned to another cluster request
with different computers for a different user. Inconsistent results could happen if the cluster
scripts are run again.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[ https://issues.apache.org/jira/browse/VCL-999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15609478#comment-15609478
]
ASF subversion and git services commented on VCL-999:
-----------------------------------------------------
Commit 1766727 from arkurth@apache.org in branch 'vcl/trunk'
[ https://svn.apache.org/r1766727 ]
VCL-999
Rewrote much of UnixLab.pm. Added initialize subroutine which sets ssh_port and ssh_user keys
in the OS object. These are used by OS.pm::execute and is_ssh_responding so that the correct
port and username are used.
Replaced OS.pm::get_current_image_info with get_current_imagerevision_id. The old subroutine
accepted various text strings to specify which piece of data to retrieve. This isn't very
elegant. Separate subs should be written for each if necessary. All of the callers of get_current_image_info
really only needed the imagerevision ID.
Updated OS.pm::is_ssh_responding to not check both port 22 and 24. It now checks if $self->{ssh_port}
is set. If not, defaults only to 22.
Added OS.pm::wait_for_port_open and wait_for_port_closed. Similar functionality had existed
in UnixLab.pm but was messy and didn't use the code_loop_timeout sub for the looping countdown.
Other
Added double quotes to the message string in Linux.pm::notify_user_console. It wasn't working
if the message contained a newline.
> Rework UnixLab.pm
> -----------------
>
> Key: VCL-999
> URL: https://issues.apache.org/jira/browse/VCL-999
> Project: VCL
> Issue Type: Improvement
> Components: vcld (backend)
> Reporter: Andy Kurth
> Assignee: Andy Kurth
> Fix For: 2.5
>
>
> The {{UnixLab.pm}} module contains a lot of outdated, sloppy code and needs to be reworked.
It's currently functional but generates several warning messages are generated in vcld.log.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Thanks for the info Josh.
Let me know if you need any help refactoring.
Thanks.
Junaid.
On Thu, Oct 20, 2016 at 8:18 AM, Josh Thompson <josh_thompson@ncsu.edu>
wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Junaid,
>
> Good to hear from you - we've just been working on incorporating your AD
> work
> this week. Thanks for contributing it - sorry it's taken so long to
> incorporate it.
>
> I'd recommend against cleaning out the user entries because they are tied
> to
> so many other table entries. If you have concerns of having old user data
> in
> there that could potentially be exposed in the event of a security breach,
> I'd recommend to anonymize the unityid, firstname, lastname, preferredname,
> and email fields for the old accounts.
>
> To help with the space usage, cleaning up the continuations and querylog
> tables will be the most helpful. I'd actually recommend having a
> maintenance
> window once or twice a year to clean those tables. You can safely delete
> any
> entries from the continuations table with expiretime < NOW(). The querylog
> table is never read from - it is only written to to allow for auditing in
> the
> event of a problem or security incident. All queries by the web frontend
> that are INSERT, UPDATE, or DELETE are logged to the table. You can delete
> as many entries from querylog as you'd like based on the timestamp. If you
> know you'd never look at data in the querylog table, you can disable it by
> setting QUERYLOGGING to 0 in conf.php (that may have been added in 2.4.2).
>
> That said, because the tables are in the innodb format, deleting entries
> will
> not decrease the amount of space consumed on disk. It will free up space
> for
> future database entries that will be added without increasing the disk
> usage
> further. It's kind of like a thin provisioned VM disk file. The only way
> to
> actually reclaim the space is to backup the database by dumping it,
> deleting/recreating the database, and then doing a restore. You can also
> reconfigure your database to use individual files per innodb table and then
> run an optimize query on the table (which creates a new table, transfers
> the
> data, and deletes the old table).
>
> I hope that helps!
>
> Josh
>
> On Wednesday, October 19, 2016 3:22:44 PM Junaid Ali wrote:
> > Hello,
> > We are currently using vcl version 2.3.2 in our environment. We use
> Active
> > Directory for LDAP Authentication and user accounts get added to specific
> > groups in VCL based on user access rights. Since its deployment, the VCL
> > MySQL database has not been purged of historical data. Curerntly the
> > querylog table is using 1.5 Gb and continuations table is using 750 Mb
> > storage. We are interested in cleaning the user accounts that exist in
> the
> > database and are not active (during the current academic year). Is there
> a
> > recommended procedure for purging user accounts from the VCL database? I
> > understand there is user data referenced in other VCL tables (e.g. log)
> > that needs to be deleted before the actual user account can be purged.
> >
> > Thanks
> >
> > Junaid Ali
> > Systems & Virtualization Engineer,
> > Office of Technology Services/IIT,
> > Chicago, IL - 60616
> - --
> - -------------------------------
> Josh Thompson
> VCL Developer
> North Carolina State University
>
> my GPG/PGP key can be found at pgp.mit.edu
>
> All electronic mail messages in connection with State business which
> are sent to or received by this account are subject to the NC Public
> Records Law and may be disclosed to third parties.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iEYEARECAAYFAlgIxEQACgkQV/LQcNdtPQO6IQCdHsj3kLw769IFH7c6zS/cHaI0
> t/8An13UtK+iT1wHCIV0NdW06Oss3Uau
> =Yj8G
> -----END PGP SIGNATURE-----
>
>

[ https://issues.apache.org/jira/browse/VCL-997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15595415#comment-15595415
]
Andy Kurth commented on VCL-997:
--------------------------------
The backend code is working but leaving issue open for now. The _reservation\_info.json_
currently contains a lot of data. It could be pruned or organized differently.
> Create reservation info file on reserved computer
> -------------------------------------------------
>
> Key: VCL-997
> URL: https://issues.apache.org/jira/browse/VCL-997
> Project: VCL
> Issue Type: New Feature
> Components: vcld (backend)
> Reporter: Andy Kurth
> Assignee: Andy Kurth
>
> It would be useful if a file was created on loaded computers containing various aspects
of the reservation. Such a file could be used by post-load, post-reserve, and other scripts
to customize the computer based on reservation information such as user accounts, account
passwords, etc.
> One option would be a simple text file with key-value pairs. This is not optimal. Something
more structured such as JSON would be better.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[ https://issues.apache.org/jira/browse/VCL-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15595372#comment-15595372
]
ASF subversion and git services commented on VCL-867:
-----------------------------------------------------
Commit 1766041 from [~jfthomps] in branch 'vcl/trunk'
[ https://svn.apache.org/r1766041 ]
VCL-277 - Add support for images to join Active Directory domains
VCL-867 - Active Directory Authentication for Windows VM's
addomain.php:
-modified AJsaveResource, AJeditResource, and validateResourceData: commented out code for
logindescription
-modified addResource: commented out code for logindescription; modified INSERT query for
resource table to have a subselect to get resourcetype.id based on the type name addomain
instead of having 19 hard coded
-modified addEditDialogHTML: added helpIcons for several input fields and corresponding tooltips
- still need to fill in the content of the tooltips
-removed 2nd definition of checkResourceInUse (I think I had copied it from the image code
to modify but then wrote it separately)
privileges.php:
-modified getResourcePrivRowHTML: added addomain exception to not print checkboxes for available
and manageMapping
-modified jsonGetResourceGroupMembers: modified if/elseif conditionals that set $field to
have an else to handle setting $field to 'name' and removed specific elseif's that set it
to 'name'
utils.php:
-modified getResourceGroupMembers: changed hard coded resource type ids to be subselects to
get the id based on the resource type name
-modified isAvailable and debugIsAvailable: found 2 locations calling debugIsAvailable with
$loc being the same number (19), changed the 2nd one to be 22
-modified getADdomains: commented out code for logindescription
addomain.js:
-modified addNewResource: set password and password2 to be required
-modified inlineEditResourceCB: set password and password2 to not be required; commented out
code for logindescription
-modified resetEditResource, saveResource, and saveResourceCB: commented out code for logindescription
> Active Directory Authentication for Windows VM's
> ------------------------------------------------
>
> Key: VCL-867
> URL: https://issues.apache.org/jira/browse/VCL-867
> Project: VCL
> Issue Type: New Feature
> Components: database, vcld (backend), web gui (frontend)
> Reporter: Junaid Ali
> Labels: features
> Fix For: 2.5
>
> Attachments: managementnode.patch, vmadsauth.sql, web.patch
>
>
> The current VCL application creates local user accounts for each reservation. There is
a need to provide active directory authentication so as to provide access to domain resources
like profile and network shares during the VCL reservation.
> This patch updates the VCL database by creating two additional tables:
> activedirectorydomain -> used to store active directory related information
> imageactivedirectorydomain -> used to store mapping of which images use which active
directory domain.
> A new column is added to the reservation table to hold current active directory information
for that particular reservation.
> The patch updates the VCL backed (vcld) to add functionality to make the windows images
part of the active directory domain. It also sets the computer's hostname to be the same as
defined in the database. This is done to prevent creation of a lot of temporary computer objects
within Active Directory. The process of domain join add's two reboots (one for hostname update
and one for domain join). After each reboot the cygwin_rebase scripts are run to reconfigure
SSHD.
> The patch also updates the VCL frontend to allow management of Active directory domains
within the system and also manage the association of VCL images and active directory domains.
There is an option to enable moving computer objects to specific Active directory Organization
Unit's for better grouping and ability to apply custom policies to custom group of images
on the Active directory side. This option was working in Cygwin 1.5 but stopped working in
Cygwin 1.7 due to some path issues. I left this option in the front-end while I look for resolution
within Cygwin 1.7.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[ https://issues.apache.org/jira/browse/VCL-277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15595371#comment-15595371
]
ASF subversion and git services commented on VCL-277:
-----------------------------------------------------
Commit 1766041 from [~jfthomps] in branch 'vcl/trunk'
[ https://svn.apache.org/r1766041 ]
VCL-277 - Add support for images to join Active Directory domains
VCL-867 - Active Directory Authentication for Windows VM's
addomain.php:
-modified AJsaveResource, AJeditResource, and validateResourceData: commented out code for
logindescription
-modified addResource: commented out code for logindescription; modified INSERT query for
resource table to have a subselect to get resourcetype.id based on the type name addomain
instead of having 19 hard coded
-modified addEditDialogHTML: added helpIcons for several input fields and corresponding tooltips
- still need to fill in the content of the tooltips
-removed 2nd definition of checkResourceInUse (I think I had copied it from the image code
to modify but then wrote it separately)
privileges.php:
-modified getResourcePrivRowHTML: added addomain exception to not print checkboxes for available
and manageMapping
-modified jsonGetResourceGroupMembers: modified if/elseif conditionals that set $field to
have an else to handle setting $field to 'name' and removed specific elseif's that set it
to 'name'
utils.php:
-modified getResourceGroupMembers: changed hard coded resource type ids to be subselects to
get the id based on the resource type name
-modified isAvailable and debugIsAvailable: found 2 locations calling debugIsAvailable with
$loc being the same number (19), changed the 2nd one to be 22
-modified getADdomains: commented out code for logindescription
addomain.js:
-modified addNewResource: set password and password2 to be required
-modified inlineEditResourceCB: set password and password2 to not be required; commented out
code for logindescription
-modified resetEditResource, saveResource, and saveResourceCB: commented out code for logindescription
> Add support for images to join Active Directory domains
> -------------------------------------------------------
>
> Key: VCL-277
> URL: https://issues.apache.org/jira/browse/VCL-277
> Project: VCL
> Issue Type: New Feature
> Components: database, vcld (backend), web gui (frontend)
> Affects Versions: 2.0
> Reporter: Andy Kurth
> Fix For: 2.5
>
>
> There have been multiple requests for Active Directory integration for VCL images. VCL
image should be able to join an AD domain when they are loaded. A web utility will need to
be created to administer this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[ https://issues.apache.org/jira/browse/VCL-997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15595337#comment-15595337
]
ASF subversion and git services commented on VCL-997:
-----------------------------------------------------
Commit 1766039 from arkurth@apache.org in branch 'vcl/trunk'
[ https://svn.apache.org/r1766039 ]
VCL-997
Changed location to C:\Users\Administrator\reservation_info.json so that users without root/Administrator
access can't read the file. Changed location on Linux to /root/reservation_info.json and
added a call to set the permissions to 600.
> Create reservation info file on reserved computer
> -------------------------------------------------
>
> Key: VCL-997
> URL: https://issues.apache.org/jira/browse/VCL-997
> Project: VCL
> Issue Type: New Feature
> Components: vcld (backend)
> Reporter: Andy Kurth
> Assignee: Andy Kurth
>
> It would be useful if a file was created on loaded computers containing various aspects
of the reservation. Such a file could be used by post-load, post-reserve, and other scripts
to customize the computer based on reservation information such as user accounts, account
passwords, etc.
> One option would be a simple text file with key-value pairs. This is not optimal. Something
more structured such as JSON would be better.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Junaid,
Good to hear from you - we've just been working on incorporating your AD work
this week. Thanks for contributing it - sorry it's taken so long to
incorporate it.
I'd recommend against cleaning out the user entries because they are tied to
so many other table entries. If you have concerns of having old user data in
there that could potentially be exposed in the event of a security breach,
I'd recommend to anonymize the unityid, firstname, lastname, preferredname,
and email fields for the old accounts.
To help with the space usage, cleaning up the continuations and querylog
tables will be the most helpful. I'd actually recommend having a maintenance
window once or twice a year to clean those tables. You can safely delete any
entries from the continuations table with expiretime < NOW(). The querylog
table is never read from - it is only written to to allow for auditing in the
event of a problem or security incident. All queries by the web frontend
that are INSERT, UPDATE, or DELETE are logged to the table. You can delete
as many entries from querylog as you'd like based on the timestamp. If you
know you'd never look at data in the querylog table, you can disable it by
setting QUERYLOGGING to 0 in conf.php (that may have been added in 2.4.2).
That said, because the tables are in the innodb format, deleting entries will
not decrease the amount of space consumed on disk. It will free up space for
future database entries that will be added without increasing the disk usage
further. It's kind of like a thin provisioned VM disk file. The only way to
actually reclaim the space is to backup the database by dumping it,
deleting/recreating the database, and then doing a restore. You can also
reconfigure your database to use individual files per innodb table and then
run an optimize query on the table (which creates a new table, transfers the
data, and deletes the old table).
I hope that helps!
Josh
On Wednesday, October 19, 2016 3:22:44 PM Junaid Ali wrote:
> Hello,
> We are currently using vcl version 2.3.2 in our environment. We use Active
> Directory for LDAP Authentication and user accounts get added to specific
> groups in VCL based on user access rights. Since its deployment, the VCL
> MySQL database has not been purged of historical data. Curerntly the
> querylog table is using 1.5 Gb and continuations table is using 750 Mb
> storage. We are interested in cleaning the user accounts that exist in the
> database and are not active (during the current academic year). Is there a
> recommended procedure for purging user accounts from the VCL database? I
> understand there is user data referenced in other VCL tables (e.g. log)
> that needs to be deleted before the actual user account can be purged.
>
> Thanks
>
> Junaid Ali
> Systems & Virtualization Engineer,
> Office of Technology Services/IIT,
> Chicago, IL - 60616
- --
- -------------------------------
Josh Thompson
VCL Developer
North Carolina State University
my GPG/PGP key can be found at pgp.mit.edu
All electronic mail messages in connection with State business which
are sent to or received by this account are subject to the NC Public
Records Law and may be disclosed to third parties.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEARECAAYFAlgIxEQACgkQV/LQcNdtPQO6IQCdHsj3kLw769IFH7c6zS/cHaI0
t/8An13UtK+iT1wHCIV0NdW06Oss3Uau
=Yj8G
-----END PGP SIGNATURE-----

Hello,
We are currently using vcl version 2.3.2 in our environment. We use Active
Directory for LDAP Authentication and user accounts get added to specific
groups in VCL based on user access rights. Since its deployment, the VCL
MySQL database has not been purged of historical data. Curerntly the
querylog table is using 1.5 Gb and continuations table is using 750 Mb
storage. We are interested in cleaning the user accounts that exist in the
database and are not active (during the current academic year). Is there a
recommended procedure for purging user accounts from the VCL database? I
understand there is user data referenced in other VCL tables (e.g. log)
that needs to be deleted before the actual user account can be purged.
Thanks
Junaid Ali
Systems & Virtualization Engineer,
Office of Technology Services/IIT,
Chicago, IL - 60616

[ https://issues.apache.org/jira/browse/VCL-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15589277#comment-15589277
]
ASF subversion and git services commented on VCL-867:
-----------------------------------------------------
Commit 1765685 from [~jfthomps] in branch 'vcl/trunk'
[ https://svn.apache.org/r1765685 ]
VCL-277 - Add support for images to join Active Directory domains
VCL-867 - Active Directory Authentication for Windows VM's
vcl.sql:
-added definition of addomain table
-put backticks around field names for connectlog table (unrelated to this JIRA)
-added definition of imageaddomain table
-added addomain entry to resourcetype table
-added 'All AD Domains' entry to resourcegroup table
-added entries for administer and manageGroup for 'All AD Domains' group to resourcepriv table
-added addomainAdmin entry to userprivtype table
-added entries to give admin user and adminUsers group addomainAdmin privilege at admin node
in userpriv table
update-vcl.sql:
-added definition of addomain table
-put backticks around field names for connectlog table (unrelated to this JIRA)
-added definition of imageaddomain table
-added insert for addomain entry to resourcetype table
-added insert for 'All AD Domains' entry to resourcegroup table
-added inserts for entries for administer and manageGroup for 'All AD Domains' group to resourcepriv
table
-added insert for addomainAdmin entry to userprivtype table
-added inserts for entries to give admin user and adminUsers group addomainAdmin privilege
at admin node in userpriv table
> Active Directory Authentication for Windows VM's
> ------------------------------------------------
>
> Key: VCL-867
> URL: https://issues.apache.org/jira/browse/VCL-867
> Project: VCL
> Issue Type: New Feature
> Components: database, vcld (backend), web gui (frontend)
> Reporter: Junaid Ali
> Labels: features
> Fix For: 2.5
>
> Attachments: managementnode.patch, vmadsauth.sql, web.patch
>
>
> The current VCL application creates local user accounts for each reservation. There is
a need to provide active directory authentication so as to provide access to domain resources
like profile and network shares during the VCL reservation.
> This patch updates the VCL database by creating two additional tables:
> activedirectorydomain -> used to store active directory related information
> imageactivedirectorydomain -> used to store mapping of which images use which active
directory domain.
> A new column is added to the reservation table to hold current active directory information
for that particular reservation.
> The patch updates the VCL backed (vcld) to add functionality to make the windows images
part of the active directory domain. It also sets the computer's hostname to be the same as
defined in the database. This is done to prevent creation of a lot of temporary computer objects
within Active Directory. The process of domain join add's two reboots (one for hostname update
and one for domain join). After each reboot the cygwin_rebase scripts are run to reconfigure
SSHD.
> The patch also updates the VCL frontend to allow management of Active directory domains
within the system and also manage the association of VCL images and active directory domains.
There is an option to enable moving computer objects to specific Active directory Organization
Unit's for better grouping and ability to apply custom policies to custom group of images
on the Active directory side. This option was working in Cygwin 1.5 but stopped working in
Cygwin 1.7 due to some path issues. I left this option in the front-end while I look for resolution
within Cygwin 1.7.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (VCL-998) Request may be left in pending state if database connection is lost"Andy Kurth (JIRA)" <jira@apache.org>urn:uuid:%3cJIRA-13013543-1476886184000-29057-1476886438380@Atlassian-JIRA%3e2016-10-19T14:13:58Z

[jira] [Created] (VCL-998) Request may be left in pending state if database connection is lost"Andy Kurth (JIRA)" <jira@apache.org>urn:uuid:%3cJIRA-13013543-1476886184000-29044-1476886198420@Atlassian-JIRA%3e2016-10-19T14:09:58Z

[ https://issues.apache.org/jira/browse/VCL-997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15586065#comment-15586065
]
ASF subversion and git services commented on VCL-997:
-----------------------------------------------------
Commit 1765484 from arkurth@apache.org in branch 'vcl/trunk'
[ https://svn.apache.org/r1765484 ]
VCL-997
Added subroutines:
DataStructure.pm::get_reservation_info_json_string
OS.pm::get_reservation_info_json_file_path
OS.pm::create_reservation_info_json_file
OS.pm::delete_reservation_info_json_file
Windows.pm::get_reservation_info_json_file_path
utils.pm::prune_array_reference
utils.pm::prune_hash_child_references
utils.pm::prune_hash_reference
OS.pm::create_reservation_info_json_file gets called from reserved.pm::process only if a variable
named 'enable_experimental_features' is true in the database.
This file is removed when a computer is sanitized in reclaim.pm::call_os_sanitize.
> Create reservation info file on reserved computer
> -------------------------------------------------
>
> Key: VCL-997
> URL: https://issues.apache.org/jira/browse/VCL-997
> Project: VCL
> Issue Type: New Feature
> Components: vcld (backend)
> Reporter: Andy Kurth
> Assignee: Andy Kurth
>
> It would be useful if a file was created on loaded computers containing various aspects
of the reservation. Such a file could be used by post-load, post-reserve, and other scripts
to customize the computer based on reservation information such as user accounts, account
passwords, etc.
> One option would be a simple text file with key-value pairs. This is not optimal. Something
more structured such as JSON would be better.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)