Re: [VOTE][CANCELED] release VCL 2.3 (based on RC3)
That makes sense to me, too. Aaron C On Jun 13, 2012, at 9:03 AM, Mark Gardner wrote: > Given the need to move the svn, website, etc. I prefer to go with > Aaron's suggestion. Let's get the release out and then concentrate on > moving things. > > Mark > > On Wed, Jun 13, 2012 at 8:57 AM, Aaron Peeler wrote: >> ok right, since it will take time to move the svn, website, etc. >> >> I would like to push to get 2.3 out before graduation and then target >> a minor release (2.3.1) post graduation in August time frame. >> >> What do others think? >> >> Aaron >> >> On Tue, Jun 12, 2012 at 6:37 PM, Kevan Miller wrote: >>> >>> On Jun 12, 2012, at 4:23 PM, Josh Thompson wrote: >>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It sounds like the general consensus is that it would be okay to wait until after the board votes on our graduation before releasing 2.3 as long as there is little delay after the board vote. Mentors - Do you know if we can start a vote before the board meeting and close it afterward? The idea here being not to wait another 72 hours after the board meeting to get the release out. I know for me, it would be nice to get it out by the end of next week. I'll be on vacation the last week of June and would prefer not to work on cutting the release during that time. >>> >>> Hmm. I'm not sure that would be possible… A PMC votes on (and is >>> responsible for) releases. Before graduation, the PMC is the Incubator PMC. >>> Afterwards it's the VCL PMC. BTW, there are legal reasons why releases are >>> operations of a PMC. Seems simpler to wait and release as a true PMC. But >>> you can check with the IPMC/Board to see if it would be feasible… >>> >>> BTW, note that there will be some time required to move the mailing lists, >>> web site, etc… svn moves, also… >>> >>> --kevan >> >> >> >> -- >> Aaron Peeler >> Program Manager >> Virtual Computing Lab >> NC State University >> >> 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. > > > > -- > Mark Gardner > --
Re: [VOTE][CANCELED] release VCL 2.3 (based on RC3)
I don't like the idea of another delay, but if this is just a matter of waiting one week until after the ASF meeting on June 20, then I would be inclined to wait -- especially if we have a quality release candidate ready to go. At the same time, though, I would really encourage everyone who plans to test a post-graduation RC4 to take a close look at the current RC3. Aaron C On Jun 12, 2012, at 3:25 PM, Henry Schaffer wrote: > While I'd like to see 2.3 out, I think that the attention to testing > is really important and shouldn't be rushed. Even non-code aspects > such as getting the cwiki documentation all lined up and the obsolete > stuff removed is important. > > Isn't the vote on graduation due later this month? If so, I think > that doing an extra week or two of cleaning/polishing might be worth > it in terms of looking good to the community. And then if the release > is post-graduation kevan's comments apply and 2.3 will look more like > a really solid product. > > That's my 2¢ > > --henry > > On Tue, Jun 12, 2012 at 2:42 PM, Aaron Peeler wrote: >> I like the idea of having a post graduation release, but also would >> like to get 2.3 out. >> >> I would support either decision in how the community wants to go. >> >> Aaron >> >>> >>> At this point, we may want to consider a 2.3 release post-graduation. There >>> are some advantages for this. There will be some desires for a >>> non-incubating release (no incubator in the name, no incubator disclaimer, >>> etc). >>> >>> --kevan
Re: [DISCUSS] stop vote on RC1 and cut RC2
Thanks for your understanding. I updated trunk with the shibboleth-related fixes (adding user.validated to the database scripts, fixing the global scope of $addUserFuncArgs). I also took the opportunity to update the updateShibUser function so that user.validated is set to 1 whenever a user officially logs in through the standard Shibboleth channels (which makes the 'user.validated' field work as intended). Aaron C. On May 31, 2012, at 12:32 PM, Aaron Peeler wrote: > I can get the OS.pm module change. > > I also found a small change needed in the xCAT modules... nothing > critical but would be helpful. > > Aaron P. > > On Thu, May 31, 2012 at 12:21 PM, Andy Kurth wrote: >> I agree. I also found some issues with vSphere.pm connecting to >> vCenter 5 yesterday. I would like to fix this for RC2. >> -Andy >> >> On Thu, May 31, 2012 at 11:51 AM, Josh Thompson >> wrote: >>> -BEGIN PGP SIGNED MESSAGE- >>> Hash: SHA1 >>> >>> Aaron, >>> >>> You're not being a stick in the mud. I think it's great that you tested it >>> well enough to find a few things that need to be corrected - that's the >>> whole >>> point of having a community vote to do a release. I definitely consider the >>> Shibboleth issue big enough to cut a new RC (even though that requires a new >>> vote). >>> >>> All, >>> >>> Aaron has some good points. I think we should fix the issues he mentioned >>> and >>> cut RC2 for 2.3. This isn't an official vote process, but please share any >>> thoughts you have. >>> >>> Josh >>> >>> On Wednesday, May 30, 2012 9:41:12 PM Aaron Coburn wrote: >>>> -1 >>>> >>>> Sorry to a stick in the mud, guys, since I'd certainly like to see 2.3 >>>> released soon, but I encountered a few issues that I think should be fixed >>>> before cutting the release. >>>> >>>> I installed the release candidate using a fresh database, testing against a >>>> vCenter provisioning engine and Shibboleth authentication. I was using a >>>> 64-bit Windows 7 image. >>>> >>>> The first issue I encountered was that each time the management node calls >>>> 'get_file_contents', the contents of the target file are printed to the >>>> log. This is generally not an issue, but when a slice of the registry is >>>> retrieved, that amounted to ~30,000 lines in my logfile. And that happens >>>> each time an image is reloaded. (Somehow I hadn't noticed this with the >>>> code from about two weeks ago). I can certainly see the usefulness of this >>>> during development, but I don't like the fact that this is the default >>>> behavior for a release. For now, I would suggest modifying line 1789 of >>>> OS.pm: >>>> >>>> -my ($exit_status, $output) = $self->execute($command); >>>> +my ($exit_status, $output) = $self->execute($command, 0); # do not >>>> print the cmd output to the log >>>> >>>> Later, it could be nice to make this somewhat more configurable. >>>> >>>> >>>> Second, if the system is using Shibboleth it is not possible to handle >>>> users >>>> who have not previously logged in (i.e. adding someone to a group). There >>>> are two bugs preventing this from working properly. First, if someone >>>> enables ALLOWADDSHIBUSERS in conf.php but doesn't define a value in >>>> $addUserFuncArgs (I would anticipate this to be what most people using Shib >>>> would do, since there is no documentation about what that array is for), >>>> the initGlobals() function does not properly populate the addUserFuncArgs >>>> array. This can be fixed by adding $addUserFuncArgs to the list of 'global' >>>> values on line 68 in utils.php -- the current code is just modifying a >>>> local value, not the global one: >>>> >>>> -global $affilValFunc, $addUserFunc, $updateUserFunc; >>>> +global $affilValFunc, $addUserFunc, $updateUserFunc, $addUserFuncArgs; >>>> >>>> Once that change is made, though, there is also a SQL query expecting a >>>> 'validated' field in the users table. This field, however, does not exist. >>>> It is in neither update-vcl.sql nor in vcl.sql: >>>> >>>> vcl.sql, line 1079: >>>> >>>&
Re: [VOTE] Andy Kurth as PMC chair after graduation
+1 And with that, the tally for this vote is: 16 positive votes 1 neutral vote 0 negative votes At this point, with such a positive display of support from the community, I believe we can now add Andy's name to the Graduation Board Resolution. Aaron Coburn -- Aaron Coburn Systems Administrator and Programmer Academic Technology Services, Amherst College acob...@amherst.edu<mailto:acob...@amherst.edu> On May 24, 2012, at 11:03 AM, Aaron Coburn wrote: All, I would like to nominate Andy Kurth as the first VCL chair. This is a position that is responsible for the proper operation of the VCL project. Selecting someone for this position is also a necessary step in the process of graduating from incubator status to a top-level Apache project. For those of you interested in the details, they can be found here: http://incubator.apache.org/guides/graduation.html#tlp-resolution The process is like so: anyone can nominate a person to serve in this role, and these nominations are discussed and voted upon in the community. Based on the consensus from the community, the PPMC (Podling Project Management Committee) makes a recommendation to the ASF Board, which actually appoints the chair. -Aaron Coburn -- Aaron Coburn Systems Administrator and Programmer Academic Technology Services, Amherst College acob...@amherst.edu<mailto:acob...@amherst.edu>
Re: [VOTE] release VCL 2.3
-1
Sorry to a stick in the mud, guys, since I'd certainly like to see 2.3 released
soon, but I encountered a few issues that I think should be fixed before
cutting the release.
I installed the release candidate using a fresh database, testing against a
vCenter provisioning engine and Shibboleth authentication. I was using a 64-bit
Windows 7 image.
The first issue I encountered was that each time the management node calls
'get_file_contents', the contents of the target file are printed to the log.
This is generally not an issue, but when a slice of the registry is retrieved,
that amounted to ~30,000 lines in my logfile. And that happens each time an
image is reloaded. (Somehow I hadn't noticed this with the code from about two
weeks ago). I can certainly see the usefulness of this during development, but
I don't like the fact that this is the default behavior for a release. For now,
I would suggest modifying line 1789 of OS.pm:
-my ($exit_status, $output) = $self->execute($command);
+my ($exit_status, $output) = $self->execute($command, 0); # do not print
the cmd output to the log
Later, it could be nice to make this somewhat more configurable.
Second, if the system is using Shibboleth it is not possible to handle users
who have not previously logged in (i.e. adding someone to a group). There are
two bugs preventing this from working properly. First, if someone enables
ALLOWADDSHIBUSERS in conf.php but doesn't define a value in $addUserFuncArgs (I
would anticipate this to be what most people using Shib would do, since there
is no documentation about what that array is for), the initGlobals() function
does not properly populate the addUserFuncArgs array. This can be fixed by
adding $addUserFuncArgs to the list of 'global' values on line 68 in utils.php
-- the current code is just modifying a local value, not the global one:
-global $affilValFunc, $addUserFunc, $updateUserFunc;
+global $affilValFunc, $addUserFunc, $updateUserFunc, $addUserFuncArgs;
Once that change is made, though, there is also a SQL query expecting a
'validated' field in the users table. This field, however, does not exist. It
is in neither update-vcl.sql nor in vcl.sql:
vcl.sql, line 1079:
+ `validated` tinyint(1) unsigned NOT NULL default '1',
and update-vcl.sql, lines 827-
+ --
+
+ --
+ -- Table structure for table `user`
+ --
+
+ CALL AddColumnIfNotExists('user', 'validated', "tinyint(1) unsigned NOT NULL
default '1'");
+
Once these two changes are made, however, I am able to add shib users exactly
as the documentation suggests.
Otherwise, everything else looks good.
Aaron
--
Aaron Coburn
Systems Administrator and Programmer
Academic Technology Services, Amherst College
acob...@amherst.edu<mailto:acob...@amherst.edu>
On May 30, 2012, at 2:58 PM, Josh Thompson wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kevan,
Correct - VCL is all in scripted languages; so, there are no binary releases.
I've avoided maintaining dojo in subversion both to keep the repo a little
cleaner and to avoid the problem of ending up with an old copy in there that
never gets updated.
I'll start a separate thread to discuss if others would like dojo in the repo.
Josh
On Wednesday, May 30, 2012 10:57:41 AM Kevan Miller wrote:
Here's my +1
Source, LICENSE/NOTICE, RAT, signature/checksum -- all look good to me.
Seem to recall a discussion on this before, but just to be sure. Apache
releases source code. PMC's vote on source releases. Many ASF projects also
have binary distributions (which a PMC also evaluates and uses in
evaluating the correctness of the release). The binaries are also
convenient for many users. So, you end up with source and binary
distributions of a project.
There is no VCL binary/compilation (that I know of). So, the VCL release is
a *source* release. One thing to note is that we don't maintain dojo in svn
(we could do so).
--kevan
On May 29, 2012, at 4:36 PM, Josh Thompson wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
We've finally reached a point where we do not seem to be finding any more
bugs.
I created a release artifact based off of trunk. I copied trunk to a tag
under the tags area of the repo that is named release-2.3-RC1:
http://svn.apache.org/repos/asf/incubator/vcl/tags/release-2.3-RC1/
The artifact is an export from that tag with the addition of Dojo Toolkit
version 1.6.1 with a custom VCL profile bundled in the web code. The
artifact, MD5 and SHA1 sums, and my GPG signature of it are available from
my space on people.a.o:
http://people.apache.org/~jfthomps/apache-VCL-2.3-RC1-incubating/
The list of resolved JIRA issues associated with this release can be found
under Change Log on the VCL 2.3 release page:
https://cwiki.apache.org/VCL/vc
Re: "Preferred Password" under User Preferences ?
I agree with Mark for the same reasons.
I would add, though, that there are ways to make "auto-connect" work.
We have a single-click, auto-connect system working in our VCL installation.
The basic principal is to define a protocol handler and format the URI so that
it is understandable to the target RDP application.
There are trade-offs (of course) with this approach, but it makes the VCL much
more user-friendly while retaining the security of randomized credentials.
Basically, I wrote some front-end web code so that when a user lands on the
"Connect to your reservation" page, he or she can select the desired screen
size (the default is set in user preferences) and click on "Connect".
(A screen shot is below.)
That action generates a URI such as the following:
rdp://{username}:{password}@{host}?forwardDisks=yes&forwardPrinters=yes... (and
so on with all the appropriate parameters)
The first time a browser encounters an unknown protocol such as rdp://, it will
prompt the user for a 'default application' to associate with that. The user
can select an application to use and then the login happens immediately.
The next question is which applications can handle URIs using the rdp protocol?
For OS X, the answer is easy: CoRD. You can just request that users install
that application. CoRD doesn't handle sound, so if that is necessary, your
users can still use MS Remote Desktop Client; they will just have to manually
enter their credentials.
For Linux users, RDesktop can be started from the command line with a supplied
username and password. So I simply wrote a perl script that parses the rdp://
URI and translates it into an appropriate command.
For Windows, it is a bit trickier. Basically, the protocol handlers are defined
in the system registry, and Windows' built-in RDP client doesn't accept
passwords from the command line. So in order to solve both issues, I wrote a
.NET application that, upon installation defines the appropriate protocol
handler in the registry and installs an application that can parse it. The
application is really just a thin wrapper around Microsoft's terminal services
library. I don't believe I can distribute the code for this, but I can
certainly give you some pointers on how to write something similar yourself.
Obviously, this doesn't work for iOS devices.
Best regards,
Aaron
[cid:6835B418-4B53-486C-8956-6A0DD26C1F70]
--
Aaron Coburn
Systems Administrator and Programmer
Academic Technology Services, Amherst College
acob...@amherst.edu<mailto:acob...@amherst.edu>
On May 25, 2012, at 11:35 AM, Mark Gardner wrote:
In general, I would rather keep things as they are. But if that
capability is added, I would prefer to have it be an option as the
current one-time random password is much more secure. (Our experience
is that users generally pick poor passwords. Perhaps this can be a
development-only option?)
Mark
On Fri, May 25, 2012 at 11:25 AM, Dmitri Chebotarov
mailto:dcheb...@gmu.edu>> wrote:
Hi
Would it be possible, and is it good idea in general due to possible security
risks, to add "Preferred Password" field on User Preferences page (under RDP
File Preferences or Personal Information?) to allow user to provide a password
for all his/her reservations?
Then VCL would use this password (if it's there) for reservations instead of
auto-generated password.
This is not an auto-connect option, but at least it will make it easier to use
VCL.
For the last couple days I've been using VCL for some testing and it would be
nice to have the same password for all my reservations.
--
Thank you,
Dmitri Chebotarov
Virtual Computing Lab Systems Engineer, TSD - Ent Servers & Messaging
223 Aquia Building, Ffx, MSN: 1B5
Phone: (703) 993-6175
Fax: (703) 993-3404
--
Mark Gardner
--
Re: VCL cloud broker tool - first look
Karuna, I looked at what you are proposing here, and it is quite exciting. I have recently been working a fair amount with RDF and SPARQL, and it can be very powerful. You asked for some feedback on the interface. I think this is a good start. Given the number of possible permutations of thirteen (mostly) categorical attributes, the interface you designed would be great for navigating through reasonably large image collections. For smaller collections of images, I think the number of attributes would be a bit cumbersome for the average user. The one attribute that users would most certainly want to be able to specify is one related to the software available on the image. And this would need to be a multi-valued field. (i.e. "I want MatLab, R and at least version 1.6 of JAVA's runtime environment") The way I would go about this (borrowing from the language of search engines) is to see these attributes as "facets" that help narrow a search. The value of each facet would be a constraint in the logic of your query, and these constraints could be turned on or off, affecting the result list. It should be possible to design the interface so that you could effectively eliminate all four of the blue rectangular buttons. "List all images" would be achieved by removing all selected constraints; it would also be the initial state of the interface. "Discover images that match" would not be necessary if the result list is auto-updated when any constraint is added or removed. From a user's perspective I'm not sure how "Negotiate and Finalize Image" differs from "Reserve Image". Either of them could be achieved by clicking on the name of the relevant SPARQL result. >From a systems architecture perspective, it seems that you anticipate having >this tool running in an external (e.g. Joseki) service. I assume that the >service would query the VCL API (on behalf of a given user) to identify the >list of all accessible images along with the relevant attributes for each >image. By extending the API slightly, I can see how this could work very well. >Using the VCL's API, reservations could also be made and managed directly >through this brokering tool. Thanks for preparing this information. I look forward to seeing more! Aaron -- Aaron Coburn Systems Administrator and Programmer Academic Technology Services, Amherst College acob...@amherst.edu<mailto:acob...@amherst.edu> On May 23, 2012, at 5:56 PM, Karuna P Joshi wrote: Hello, I have designed the User interface for the VCL cloud broker tool and have uploaded the screenshot of this interface into the JIRA issues wiki. I look forward to feedback on the interface from VCL developers. On a related note, how does one assign the JIRA issue ? I want to assign this issue (VCL-577) to myself, but the field appears un-editable. regards, Karuna Karuna Pande Joshi PhD Candidate, CSEE Dept, UMBC kjos...@umbc.edu<mailto:kjos...@umbc.edu>, karuna.jo...@umbc.edu<mailto:karuna.jo...@umbc.edu>
[VOTE] Andy Kurth as PMC chair after graduation
All, I would like to nominate Andy Kurth as the first VCL chair. This is a position that is responsible for the proper operation of the VCL project. Selecting someone for this position is also a necessary step in the process of graduating from incubator status to a top-level Apache project. For those of you interested in the details, they can be found here: http://incubator.apache.org/guides/graduation.html#tlp-resolution The process is like so: anyone can nominate a person to serve in this role, and these nominations are discussed and voted upon in the community. Based on the consensus from the community, the PPMC (Podling Project Management Committee) makes a recommendation to the ASF Board, which actually appoints the chair. -Aaron Coburn -- Aaron Coburn Systems Administrator and Programmer Academic Technology Services, Amherst College acob...@amherst.edu<mailto:acob...@amherst.edu>
Re: [DISCUSS] Graduation - Prepare Board Resolution
On May 18, 2012, at 10:06 AM, Andy Kurth wrote: > I have created a Confluence page which we can use to work out the > board resolution: > https://cwiki.apache.org/confluence/display/VCL/Graduation+Board+Resolution > > Once we are comfortable with the resolution, one of the PPMC members > will propose it on the general incubator list. The areas we need to > work on are in bold. We need to define the project description and > scope. I wrote this as "dynamically provisioning and brokering remote > access to compute resources". Thoughts? Thanks for writing this. It sounds great. > Please check the list of initial members to make sure I didn't leave > anyone out. This list includes both PPMC members and committers, > correct? If we are in agreement that the list will be the committers > after graduation, should the status file be changed now? > > The PPMC members also need to appoint a chair for the project. I > would be willing to do this. Anyone else interested? I would support having Andy serve as chair. > Also, 2 more issues regarding the status file: > The stock bullets under "Project info" should be removed. > > The description is currently "VCL is a management framework for > building, dispensing and managing virtual machine images across a set > of bare metal machines or systems with an installed virtual machine > hypervisor." I don't think this is quite accurate. How about "VCL is > a modular cloud computing platform which dynamically provisions and > brokers remote access to compute resources."? That sounds much better (though I believe a comma should precede 'which'). Aaron Coburn -- Aaron Coburn Systems Administrator and Programmer Academic Technology Services, Amherst College acob...@amherst.edu smime.p7s Description: S/MIME cryptographic signature
Re: MIT licensed source code
Just to ask the obvious Why not just use the openssl library for this?
Especially since the public and private keys are already being loaded in the
initGlobals() function. I know that it's interface is not nearly so nice, and
it doesn't support symmetric encryption for PHP <= 5.3, but here's some code
that could be dropped in place in utils.php:
function encryptData($data){
global $keys;
if(! $data)
return false;
openssl_public_encrypt(
$data,
$encrypted,
$keys['public']);
return trim(base64_encode($encrypted));
}
function decryptData($data){
global $keys;
if(! $data)
return false;
openssl_private_decrypt(
base64_decode($data),
$decrypted,
$keys['private']);
return trim($decrypted);
}
The other change would require modifying the initGlobals() function so that the
public/private keys were read earlier in the execution of the function, i.e.
before trying to decrypt a continuation value.
Aaron
--
Aaron Coburn
Systems Administrator and Programmer
Academic Technology Services, Amherst College
acob...@amherst.edu<mailto:acob...@amherst.edu>
On May 17, 2012, at 8:34 AM, Josh Thompson wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wednesday, May 16, 2012 10:37:02 AM Kevan Miller wrote:
On May 11, 2012, at 3:17 PM, Josh Thompson wrote:
Kevan,
Ugh. Thanks for looking at this. I guess it goes to show you can't just
trust that another project that says it is MIT licensed is *completely*
MIT
licensed. :( I'll figure out a way to deal with it. If it works out
that
bcpowmod.php and str_split.php are not actually needed, can I just remove
them? If so, do I need to document that modification somewhere?
BTW, vcl/trunk/web/.ht-inc/phpseclib/index.html refers to PHP Secure
Communications Library as LGPL-licensed. Which is contradicted by
http://phpseclib.sourceforge.net/
It looks like our documentation comes from
http://phpseclib.sourceforge.net/documentation/ -- I'd check with the
phpseclib project. Seems to be their reference to LGPL is unintended or
inconsistent. bcpowmod.php's LGPL license would seem to be a problem with
this, however…
--kevan
After looking further, there are only two files (AES.php and Rijndael.php)
needed from the phpseclib project, and both of them appear as though they were
written to be able to be included by themselves (i.e. each one contains
information about the author, the project, and the license). Both files state
that they are MIT licensed and contain that license in them. Is it normal to
just pull in specific files from another project, or is it better to include
the whole project?
My only other experience in including another open source project in one I
work on is from including the Dojo Toolkit with VCL. In that case, it seemed
to make the most sense to include the whole thing.
License wise, it seems simplest to just include the two files in the release,
but I just want to make sure we do the right thing in respecting other open
source projects.
Thanks,
Josh
- --
- ---
Josh Thompson
VCL Developer
North Carolina State University
my GPG/PGP key can be found at pgp.mit.edu<http://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.0.17 (GNU/Linux)
iEYEARECAAYFAk+08HIACgkQV/LQcNdtPQN8dgCdF/RaBttxHHuRMjuw73G9Kv34
RjYAnimOHe1R50N532Bgxi+uOjVnkgjv
=PjK8
-END PGP SIGNATURE-
Re: Install of Management Node
Arbin, I would suggest following the online documentation. Version 2.3 has not been released yet, so I would recommend following the instructions located here: https://cwiki.apache.org/confluence/display/VCL/VCL+2.2.1+Installation The documentation assumes that the management node is a RHEL or CentOS server. Aaron -- Aaron Coburn Systems Administrator and Programmer Academic Technology Services, Amherst College acob...@amherst.edu<mailto:acob...@amherst.edu> On May 16, 2012, at 8:41 PM, Sanders, Arbin D wrote: All, What packages are needed when installing CentOS for the management node? This will be my first time installing CentOS from scratch and I would like to know how you all install it. Thanks! Arbin Darren Sanders IT Manager – Academic Computing North Carolina Central University 712 Cecil Street Suite 3014 Durham, NC 27707 919.530.6307 919.530.5097 (Fax) For the Latest ITS Updates and Tips Join Us Online <http://www.facebook.com/profile.php?id=66100342#!/pages/Durham-NC/NCCU-Eagle-Technical-Assistance-Center-ETAC/249508718552?v=info> <http://twitter.com/NCCUETAC> CONFIDENTIALITY: This email (including any attachments) may contain confidential, proprietary and privileged information, and unauthorized disclosure or use is prohibited. If you received this email in error, please notify the sender and delete this e-mail from your system. __ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com __
[jira] [Assigned] (VCL-560) cleartext password stored in VMProfile table
[ https://issues.apache.org/jira/browse/VCL-560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Coburn reassigned VCL-560: Assignee: Aaron Coburn > cleartext password stored in VMProfile table > > > Key: VCL-560 > URL: https://issues.apache.org/jira/browse/VCL-560 > Project: VCL > Issue Type: Bug > Components: database, vcld (backend), web gui (frontend) >Affects Versions: 2.2.1 >Reporter: Aaron Coburn > Assignee: Aaron Coburn > Labels: security > Attachments: managementnode.patch, vmprofile.alter.sql, web.patch > > > To provide some background, we are setting up a VCL system for several > institutions, using multiple, physically distributed management nodes (each > located at different institutions). Each management node will control its own > VMware infrastructure of one or more hosts while all accessing the central > vcl database. > As you know, each VMhost draws its configuration information from the > `vmprofile` table, including information for accessing that VMhost > infrastructure. For vSphere-based systems, the management node extracts login > credentials from the `username` and `password` fields. The other API modules > do not require the password field. The problem, however, is that the > passwords are stored in cleartext. > Yes, cleartext. > This means that if the VCL is using the vSphere API, anyone from institution > X who has access to the VCL database could easily access the login > credentials for the VM Host(s) at institution Y. The other issue is that > these passwords are being transferred in cleartext between database and > management nodes, so anyone listening in on the wire could also, potentially, > gain access to the VMware infrastructure. Furthermore, while the passwords > are masked in the web UI behind 'password' fields, the ajax call that > populates those fields can easily be inspected in order to get the actual > text. I can see how this isn't such an issue if a VCL system is running > within a single institution inside a single network, but in our case, that is > not the situation. > A compounding issue is that the web UI allows admins to enter the passwords > for VMhost profiles, which means that there would need to be a mechanism for > making sure that the password for the VMprofile at institution X isn't > encrypted using the same key as the password for the corresponding profile at > institution Y. > To solve this, I have written some code that performs asymmetric key > encryption so that the passwords are stored in a more secure format. Attached > are the relevant patch files. > Effectively, what I have done is add three fields to the `vmprofile` table: > rsa_pub: a string containing a public key > rsa_key: the location of the corresponding private key (i.e. > "/etc/vcl/vmhost01.key") > encrypted_passwd: the RSA-encrypted password. (There isn't a strong reason to > have this be a separate field from the existing password field, but > separating the two made it easier to test.) > Next, I added additional input fields in the VMProfile UI for accepting > rsa_pub and rsa_key. I have also updated the javascript code to support this. > If an RSA public key is supplied, the vm.php file will encrypt the incoming > password using the openssl_* functions that come with most distributions of > PHP. The encrypted password is stored in the `encrypted_passwd` field and the > `password` field is set to NULL. This causes the web UI not to show the > masked passwords, which is a behavior that I preferred to have, though others > may prefer something different. The encryption function was put in utils.php > and called encryptDataAsymmetric($data, $public_key) -- it more or less > follows the style of the existing encryptData($data) function. > Finally, vcld needs to be able to decrypt the data, so I added some code to > VCL::utils. First, I expanded the vmhost/vmprofile SQL statement to include > the new rsa_key and encrypted_passwd fields. Then, vcld will check whether a > key exists in the location specified, and if so, it will use that key to > decrypt the password. The decrypted password is then put into the data > structure in the expected location: vmprofile.password > The perl code relies on one additional library: Crypt::OpenSSL::RSA, which > has its own set of dependencies, but these are all available on the EPEL > repository or CPAN. I would add that the Crypt::OpenSSL::RSA library is quite > mature and well maintained. > I wrote this code so tha
[jira] [Resolved] (VCL-499) support for controlling VMware vCenter infrastructure through the vSphere SDK
[
https://issues.apache.org/jira/browse/VCL-499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Coburn resolved VCL-499.
--
Resolution: Fixed
Assignee: Aaron Coburn
Added code to control a cluster of VMWare hosts through a vCenter host.
> support for controlling VMware vCenter infrastructure through the vSphere SDK
> -
>
> Key: VCL-499
> URL: https://issues.apache.org/jira/browse/VCL-499
> Project: VCL
> Issue Type: Improvement
> Components: vcld (backend)
> Environment: VMware vCenter infrastructure
>Reporter: Aaron Coburn
> Assignee: Aaron Coburn
>Priority: Minor
> Fix For: 2.3
>
> Attachments: Cluster.pm, vCenter.pm, vCenter.pm
>
>
> The VCL's vSphere SDK module supports direct communication with ESX hosts,
> but not with the vCenter. This is relevant for VMware clusters with
> distributed resource scheduling enabled.
> I have written a module as a subclass of the vSphere_SDK package, which I
> have called vCenter.pm. This works with version 2.2.1. We use this in the VCL
> implementation at Amherst College. The vCenter module makes two primary
> changes in how the vSphere_SDK package works. First, it reimplements any call
> to VIExt::get_host_view(), which does not work in the context of a vCenter.
> And secondly, moving and copying a virtual disk by means of the
> VirtualDiskManager does not work with a vCenter connection, so these
> functions had to be manually implemented using a FileManager object.
> In addition to the vCenter package, there is a VMware::Cluster module that
> redefines the value of
> $VCL::Module::Provisioning::VMware::VMware::VSPHERE_SDK_PACKAGE. This is a
> subclass of the VMware package and is the package referenced in the VCL's
> "module" table.
> For our implementation, I also added a 'datacenter' value to vcld.conf which
> provides the name of the datacenter.
> The corresponding changes in utils.pm are here:
> 223d222
> < $DATACENTER
> 264d262
> <our ($DATACENTER) = 0;
> 434,437d431
> < #Datacenter name
> < if ($l =~ /datacenter=([-a-zA-Z0-9]+)/) {
> < $DATACENTER = $1;
> < }
> (It would be more elegant to add a field to the database for this, as it
> corresponds to the entry in vmprofile, but this was simpler to implement)
> The VMware::Cluster and VMware::vCenter modules are attached to this issue as
> files.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Which version of Linux?
We use CentOS 5.6 and RHEL 6.2. There was an attempt some time ago to use Debian on a second management node; we got most of the way there, but in the end it was much easier to just use RHEL. -- Aaron Coburn Systems Administrator and Programmer Academic Technology Services, Amherst College acob...@amherst.edu<mailto:acob...@amherst.edu> On May 10, 2012, at 3:13 PM, Waldron, Michael H wrote: We are running RHEL 5.8 for both. Mike Waldron Systems Specialist ITS Research Computing University of North Carolina at Chapel Hill CB #3420, ITS Manning, Rm 2509 919-962-9778 From: Sanders, Arbin D [asand...@nccu.edu<mailto:asand...@nccu.edu>] Sent: Thursday, May 10, 2012 3:07 PM To: 'vcl-dev@incubator.apache.org<mailto:vcl-dev@incubator.apache.org>'; 'vcl-u...@incubator.apache.org<mailto:vcl-u...@incubator.apache.org>' Subject: Which version of Linux? All, I am wondering what versions of Linux are you all running for your production management node and your development management node. Arbin Darren Sanders IT Manager – Academic Computing North Carolina Central University 712 Cecil Street Suite 3014 Durham, NC 27707 919.530.6307 919.530.5097 (Fax) For the Latest ITS Updates and Tips Join Us Online <http://www.facebook.com/profile.php?id=66100342#!/pages/Durham-NC/NCCU-Eagle-Technical-Assistance-Center-ETAC/249508718552?v=info> <http://twitter.com/NCCUETAC> CONFIDENTIALITY: This email (including any attachments) may contain confidential, proprietary and privileged information, and unauthorized disclosure or use is prohibited. If you received this email in error, please notify the sender and delete this e-mail from your system. __ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com __
Re: [VOTE] Apache VCL Ready to Graduate
+1 -- Aaron Coburn Systems Administrator and Programmer Academic Technology Services, Amherst College acob...@amherst.edu<mailto:acob...@amherst.edu> On May 10, 2012, at 11:01 AM, Andy Kurth wrote: This vote is to determine if the Apache VCL community believes the project is ready to graduate from the incubator to a top level project. Everyone in the community is encouraged to vote. Please reply expressing one of the following: +1 : yes, Apache VCL is ready to graduate to a top level project 0 : ambivalent -1 : no, Apache VCL is not ready to graduate to a top level project This vote will be closed on Tuesday, May 15, 2012 at 5:00 pm EST. If this vote passes, the community will draft a board resolution and present it to the IPMC. Thank You, Andy Kurth
[jira] [Commented] (VCL-576) Finalizing for 2.3 release
[ https://issues.apache.org/jira/browse/VCL-576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13271799#comment-13271799 ] Aaron Coburn commented on VCL-576: -- The undefined index error appears to be related to an artifact of the "No Image" image in the database. The SQL statement inserts the "no image" image as id=1, but the resource index expects it to be id=4. Changing that seems to fix some of the errors. > Finalizing for 2.3 release > -- > > Key: VCL-576 > URL: https://issues.apache.org/jira/browse/VCL-576 > Project: VCL > Issue Type: Task >Reporter: Aaron Peeler > Fix For: 2.3 > > > A jira issue for general fixes and tasks related to the 2.3 release candidate > - testing > - install notes > - upgrade notes -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (VCL-576) Finalizing for 2.3 release
[ https://issues.apache.org/jira/browse/VCL-576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13271766#comment-13271766 ] Aaron Coburn commented on VCL-576: -- On a fresh install with no images, there are many errors in the web interface. Many seem to be related to an "Undefined index" in the computers.php files, whenever PHP is trying to lookup this value: $images[$data["currentimgid"]["prettyname"] > Finalizing for 2.3 release > -- > > Key: VCL-576 > URL: https://issues.apache.org/jira/browse/VCL-576 > Project: VCL > Issue Type: Task >Reporter: Aaron Peeler > Fix For: 2.3 > > > A jira issue for general fixes and tasks related to the 2.3 release candidate > - testing > - install notes > - upgrade notes -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (VCL-576) Finalizing for 2.3 release
[ https://issues.apache.org/jira/browse/VCL-576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13271752#comment-13271752 ] Aaron Coburn commented on VCL-576: -- A few comments: 1. The site looks very strange on a Mac with Safari, and dojo doesn't appear to work -- which renders most of the site nonfunctional. The site seems fine with Firefox. 2. In the web code, in secrets-default.php, shouldn't the $cryptkey variable really be $mcryptkey? and shouldn't there be a stub for $mcryptiv? 3. There should be some description for how to install Dojo and which version to use. > Finalizing for 2.3 release > -- > > Key: VCL-576 > URL: https://issues.apache.org/jira/browse/VCL-576 > Project: VCL > Issue Type: Task >Reporter: Aaron Peeler > Fix For: 2.3 > > > A jira issue for general fixes and tasks related to the 2.3 release candidate > - testing > - install notes > - upgrade notes -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: VCL 2.3
Josh, I am setting up a fresh install of the VCL off of trunk to test the new code. I am wondering, however, about Dojo -- first, there is no information in the INSTALLATION or UPGRADE files about dojo. Second, is it necessary to use the Dojo Toolkit v1.6 or will v1.7.2 (the current release) work? And where can I find the custom built profiles? They don't seem to be in the repository. The web code seems to be looking for them in the dojo/dojo/ directory, but wouldn't it make more sense to put those in the js/ directory and keep the contents of the dojo directory limited to the actual dojo release? Thanks! Aaron Coburn On May 1, 2012, at 1:50 PM, Josh Thompson wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > You'll also need to download the Dojo Toolkit v1.6, put it in the main web > code directory, and name it 'dojo'. You'll see some errors about a missing > .js file for most of the pages, but you can ignore them - the missing files > are custom compiled dojo profiles for VCL that will be included in the > release. When they are missing, dojo just uses everything from the dojo > release. > > Josh > > On Tuesday, May 01, 2012 1:37:19 PM Aaron Peeler wrote: >> Hi Dmitri, >> >> Yes. The svn repo is: >> https://svn.apache.org/repos/asf/incubator/vcl/trunk >> >> I've completed the UPGRADE notes: >> https://svn.apache.org/repos/asf/incubator/vcl/trunk/UPGRADE >> >> So it might be easier to do a 2.2.1 install and follow the upgrade >> notes, but use svn co from truck to /root/apache-VCL-23-incubating, >> since there isn't a release candidate yet >> >> I try to run through and update the INSTALLATION file tomorrow. >> >> https://svn.apache.org/repos/asf/incubator/vcl/trunk/INSTALLATION >> >> Aaron >> >> On Tue, May 1, 2012 at 1:11 PM, Dmitri Chebotarov wrote: >>> Hi >>> >>> Is it possible to checkout VCL 2.2.3 code? What is the SVN/GIT address? >>> >>> I'm getting test servers ready for VCL 2.2.3. Also looking for long-term >>> server reservations options and been reading that VCL 2.2.3 provides >>> support for this. >>> >>> Are there any docs/drafts on the install procedure and requirement for >>> 2.2.3? >>> >>> Thank you. >>> -- >>> Dmitri Chebotarov >>> Virtual Computing Lab Systems Engineer, TSD - Ent Servers & Messaging >>> 223 Aquia Building, Ffx, MSN: 1B5 >>> Phone: (703) 993-6175 >>> Fax: (703) 993-3404 > - -- > - --- > 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.0.17 (GNU/Linux) > > iEYEARECAAYFAk+gIlsACgkQV/LQcNdtPQPZpQCeN29V1cZ989+C3ATpdUjnaHJj > zbUAnRmC1XXDUviAKvrRGIMS82prdNJ9 > =DC1p > -END PGP SIGNATURE- > smime.p7s Description: S/MIME cryptographic signature
Re: Rework the Apache VCL website?
On May 4, 2012, at 1:00 PM, Andy Kurth wrote: > On Fri, May 4, 2012 at 10:46 AM, Aaron Coburn wrote: >> As for the website, I agree that some design work would be really useful. I >> am assuming that ASF would provide a hosting arrangement, i.e. a domain like >> vcl.apache.org? Would that also include server space to run any type of CMS? > > Yes, ASF hosts all project websites and provides server space. > If/when we graduate, the podling website will be moved to > vcl.apache.org. Apache provides a CMS but it is up to the community > whether to use it or something else as long as the content is static. > More info is here: > http://www.apache.org/dev/project-site.html > -and- > http://www.apache.org/dev/cms.html Thanks, I read about Apache's CMS, and I don't see any compelling reason not to use that. It supports both HTML and Markdown formats. Updates are managed by subversion, and it seems like it will be easy to use. Aaron Coburn >> Confluence is a nice all-in-one package, though if you are considering a >> complete overhaul of the site, I could also recommend a system like Drupal >> (MySQL + PHP). Drupal has a lot of bells and whistles that can make for a >> very nice, highly interactive site. The downside of drupal is that it is not >> specifically designed to handle software documentation. On the other hand, >> if we only need to serve static html pages that focus on documentation, etc, >> I can also recommend Sphinx. The downside of Sphinx is that it is really >> best for Python and C++ projects, and it doesn't support web-based updates >> -- it does create excellent sites, though. > > I also like Drupal but don't think it can be used due to the static > requirement. We actually use this for NCSU's VCL front page. > > I'm not familiar with Sphinx. It looks like at least one other > project is using Sphinx: > http://chemistry.apache.org/python/docs/docs.html > > -Andy > > > On Wed, Dec 7, 2011 at 7:54 AM, Aaron Peeler wrote: >> Yes, I agree the site needs to be updated. I'm fine to move to ASF >> CMS, especially if this the future direction. >> >> Aaron >> >> On Tue, Dec 6, 2011 at 3:58 PM, Andy Kurth wrote: >>> The Apache VCL project website (https://cwiki.apache.org/VCL) could >>> use some improving. It is automatically generated from the Confluence >>> wiki site (https://cwiki.apache.org/confluence/display/VCL/Apache+VCL). >>> I'm not sure exactly how this works but some things have never worked >>> quite right... small details such as the left nav bar not showing up. >>> >>> I'd like to start reworking the site and would like ideas/help from >>> anyone interested. The first step would be to decide on an underlying >>> platform/CMS. I have nothing against Confluence but the ASF is moving >>> away from it in favor of the "ASF Content Management System". More >>> information is here: >>> http://www.apache.org/dev/cms.html >>> http://www.apache.org/dev/cmsref.html >>> >>> Tools have been written to assist in migrating from Confluence to the >>> ASF CMS. See the bottom of the wiki page: >>> http://wiki.apache.org/general/ApacheCms2010 >>> >>> At first glance this seems like a logical path to pursue. Thoughts? >>> >>> -Andy >>> >> >> >> >> -- >> Aaron Peeler >> Program Manager >> Virtual Computing Lab >> NC State University >> >> 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.
Re: [DISCUSS] Graduation
I looked through a number of existing top-level ASF project websites, and they
all appear to be serving up static HTML pages. Some of them use a wiki at
http://wiki.apache.org/{project name}; otherwise, the sites appear to be
generated by some sort of script/template combination. If there is a choice, I
would recommend following this model: using static pages as much as possible
will effectively eliminate almost all security and maintenance issues.
Most ASF sites do not have a search feature, and those that do rely on third
parties (e.g. google). It would be easy enough to follow that model, though if
we use Sphinx, it has a built-in (javascript-based) search engine.
There are a lot of template-based options for building sites, and I am
completely unfamiliar with most of them. Velocity is another ASF project, but I
have never worked with it. Several years ago I used Template::Toolkit quite a
bit, which is written in perl. Since so much of the VCL uses perl, this might
be a good option -- not that one actually needs to know perl to use it. It
would also be possible to use an XSLT-based engine, but I XSL syntax can be
very unforgiving. My current favorite is Sphinx, which relies on python to
generate the HTML.
Aaron Coburn
On May 4, 2012, at 11:51 AM, Aaron Peeler wrote:
>>
>> As for the website, I agree that some design work would be really useful. I
>> am assuming that ASF would provide a hosting arrangement, i.e. a domain like
>> vcl.apache.org? Would that also include server space to run any type of CMS?
>> Confluence is a nice all-in-one package, though if you are considering a
>> complete overhaul of the site, I could also recommend a system like Drupal
>> (MySQL + PHP). Drupal has a lot of bells and whistles that can make for a
>> very nice, highly interactive site. The downside of drupal is that it is not
>> specifically designed to handle software documentation. On the other hand,
>> if we only need to serve static html pages that focus on documentation, etc,
>> I can also recommend Sphinx. The downside of Sphinx is that it is really
>> best for Python and C++ projects, and it doesn't support web-based updates
>> -- it does create excellent sites, though.
>
> I believe we can run anything we like. ASF does provide the hosting
> and the top-level projects do have their own url
> .apache.org.
>
> I'm not up-to speed yet on what our options are or what the other
> projects are using. The Apache infrastructure team is recommending
> projects to migrate away from confluence. Has anyone else had a chance
> to research which cms tools are available supported/recommended by
> ASF?
>
>>
>> I am also a little unclear on the timeframe for modifying the website -- it
>> this something that would be done prior to graduation or upon graduation?
>
> I don't think it is a requirement, but ideally it would be nice to at
> least have a start on a new site by graduation time.
>
>
> Aaron Peeler
Re: [DISCUSS] Graduation
We began working with the VCL software about two years ago at Amherst College, and in that time, the community has grown well beyond its NCSU roots. I am seeing significantly more activity on the lists as well as more JIRA issues and contributed code from the wider community. I would also support a vote for graduation. As for the website, I agree that some design work would be really useful. I am assuming that ASF would provide a hosting arrangement, i.e. a domain like vcl.apache.org<http://vcl.apache.org>? Would that also include server space to run any type of CMS? Confluence is a nice all-in-one package, though if you are considering a complete overhaul of the site, I could also recommend a system like Drupal (MySQL + PHP). Drupal has a lot of bells and whistles that can make for a very nice, highly interactive site. The downside of drupal is that it is not specifically designed to handle software documentation. On the other hand, if we only need to serve static html pages that focus on documentation, etc, I can also recommend Sphinx. The downside of Sphinx is that it is really best for Python and C++ projects, and it doesn't support web-based updates -- it does create excellent sites, though. I am also a little unclear on the timeframe for modifying the website -- it this something that would be done prior to graduation or upon graduation? Aaron Coburn -- Aaron Coburn Systems Administrator and Programmer Academic Technology Services, Amherst College acob...@amherst.edu<mailto:acob...@amherst.edu> On May 2, 2012, at 9:14 AM, Aaron Peeler wrote: I feel we have meet our diversity issue and also expect to add more committers over the next couple of months. I would positively support a vote for graduation. I agree on the other points mentioned. Status page needs to be updated. We can work on this part easily. The web site needs to be migrated off confluence. Has anyone researched other CMS options for the website. I think this would be a good community discussion thread. Which CMS, the layout, (content, documentation, design ideas, etc.) Aaron On Tue, May 1, 2012 at 12:44 PM, Andy Kurth mailto:andy_ku...@ncsu.edu>> wrote: This thread is to discuss whether the Apache VCL community feels that this incubating project is ready to proceed with the process to graduate to a top level ASF project. There are several requirements which must be met and steps completed in order to graduate. This discussion thread is the first step towards graduation. Please review the following pages. http://incubator.apache.org/guides/graduation.html http://incubator.apache.org/incubation/Incubation_Policy.html#Graduating+from+the+Incubator There are many items described in the ASF graduation documentation which we have obviously satisfied (create a release, etc). The following are issues that I feel either need to be addressed, would be concerned about regarding board/mentor approval, or have been brought up before. Please share your thoughts. Also, please review the ASF graduation documentation and bring up anything else which might be a concern. Status File: (https://svn.apache.org/repos/asf/incubator/public/trunk/content/projects/vcl.xml) This is not up to date and is missing information. Previous board reports need to be added. News items need to be added containing the string "new committer". Doing this will cause the numberCommittersNew column on the "Status of the Clutch" page to turn green (http://incubator.apache.org/clutch.html). Also, the list of commiters in the status file and project page hasn't changed since Apache VCL started. The new committers obviously need to be added. I'm not sure how the original list was decided upon, but I feel several names should be removed since they have not contributed any code and some have not been involved in the community at all. I think the list should be Aaron Coburn, David Hutchins, Andy Kurth, James O'Dell, Aaron Peeler, Josh Thompson. Also, Brian Bouterse contributed some code a while ago. I'm not sure if he is still interested in being a committer. Diversity: ASF requirement: "The project is not highly dependent on any single contributor (there are at least 3 legally independent committers and there is no single company or entity that is vital to the success of the project)." This issue has been raised before. I feel we meet this requirement and that the community is generally diverse, can govern itself, and be self-sufficient. Website: This is not necessarily a requirement for graduation but I feel that it should be addressed prior to graduation. Our website/documentation is pretty rough and really should be redesigned. I'm guessing the board members will look at it prior to voting. In addition, there will likely be a press release if/when we graduate and website views will spike. This shouldn't hold up the graduation process, but I
Re: status of 2.3 release
Hi, Andy,
> Please feel free to make the changes you described in 1 and 2 to trunk.
Will do.
> Number 3 is a bit trickier. I'm afraid setting a name length limit in
> the database will break other things.
>
> Is the directory name also truncated or left intact? Example:
> /vmfs/volumes/datastore/vmwarewin2008-myreallylongname-v0/vmwarewin2008-myreallylongna.vmdk
> -or-
> /vmfs/volumes/datastore/vmwarewin2008-myreallylongna/vmwarewin2008-myreallylongna.vmdk
Yes, the directory names are also truncated. And I am aware of the issues you
listed below.
The way I handled this was more involved that simply modifying the db schema
(which I actually didn't touch for this). The snippet of code below is from my
.ht-inc/image.php:
$vmware_max_len = 29;
if(strlen($newname) > $vmware_max_len){
$matches = array();
if(preg_match("/^(\w+)-(\w+?)(\d*)-(v\d+)$/", $newname, $matches)){
list($base, $name, $imgid, $version) = array_splice($matches, 1);
$shortened = substr($name, 0, $vmware_max_len - 2 - strlen($imgid)
- strlen($base) - strlen($version));
$newname = $base . "-" . $shortened . $imgid . "-" . $version;
} else {
preg_match("/^(.{15}).*(.{10})$/", $newname, $matches);
$newname = $matches[1] . $matches[2];
}
}
Effectively, if the $newname is longer than 29 characters, I split up the name
into four sections (base os, image name, image id and image version). I then
keep the base os, image name and image version as-is and truncate the image
name as needed. This effectively solves the issue of image name uniqueness. (If
the code isn't able to break the imagename up into a quartet, I use a more
brute-force approach but still retain the parts of the path that ensure
uniqueness.)
What I don't like about this approach is that it enforces a VCL-wide naming
convention based on an undocumented "feature" of one particular provisioning
engine. There had been some discussion earlier on this list about letting
VMware manage its own image names and simply having the VCL follow whatever
VMware chooses to do. I like that idea in principle, but the reality is that
the VCL *is* managing the names of virtual disks. Given that structure, I
preferred the approach described above over letting VMware manage its own
names.
-Aaron
--
Aaron Coburn
Systems Administrator and Programmer
Academic Technology Services, Amherst College
acob...@amherst.edu
> Assuming the directory name is NOT truncated, what do you think about
> leaving the name in the database as-is
> (vmwarewin2008-myreallylongname-v0) even if the vmdk file name gets
> truncated. Add additional code to get the actual vmdk file name
> rather than constructing it. This would probably be done in
> VMware.pm::does_image_exist. Rather than looking for the full,
> non-truncated vmdk file path it could get a list of vmdk directory
> contents and then fetch the actual file name. Once retrieved,
> set_vmdk_file_path could be called. All of the get_vmdk* subroutines
> should then automatically use the correct value.
>
> If the directory name gets truncated then there could be additional
> problems if the truncated winds up being identical to another existing
> name. Example:
> vmwarewin2008-myreallylongname-v10
> -gets truncated to-
> vmwarewin2008-myreallylongname-v1
>
> This would cause conflicts in both the filesystem and database. The
> database wouldn't allow you to change the image name because
> image.name has a unique restriction.
>
> -Andy
>
>
> On Wed, Apr 25, 2012 at 12:58 PM, Aaron Coburn wrote:
>> I looked through the current code for
>> VCL::Module::Provisioning::VMware::vSphere_SDK
>>
>> For the most part, all of the code I submitted for the vCenter module has
>> been integrated into vSphere_SDK class.
>>
>> There are three exceptions, which I didn't see in the current code:
>>
>> 1. in the move_virtual_disk subroutine, you use the MoveVirtualDisk vSphere
>> method. This works fine on esx hosts, but in the context of a vCenter, it
>> will return a "not implemented" fault. I liked how this was handled in the
>> copy_virtual_disk subroutine: first try the method that makes sense and then
>> fall back to using the full 'CloneVM' approach if the first method doesn't
>> work. The way I had implemented this, move_virtual_disk just uses the
>> copy_virtual_disk method and then deletes the source files upon successful
>> completion. I can add that code if you would like.
>>
>> 2. in the copy_file_to and copy_file_from subroutines, I needed to add a
>> loop because the VIExt::http_put_file and V
Re: status of 2.3 release
I looked through the current code for VCL::Module::Provisioning::VMware::vSphere_SDK For the most part, all of the code I submitted for the vCenter module has been integrated into vSphere_SDK class. There are three exceptions, which I didn't see in the current code: 1. in the move_virtual_disk subroutine, you use the MoveVirtualDisk vSphere method. This works fine on esx hosts, but in the context of a vCenter, it will return a "not implemented" fault. I liked how this was handled in the copy_virtual_disk subroutine: first try the method that makes sense and then fall back to using the full 'CloneVM' approach if the first method doesn't work. The way I had implemented this, move_virtual_disk just uses the copy_virtual_disk method and then deletes the source files upon successful completion. I can add that code if you would like. 2. in the copy_file_to and copy_file_from subroutines, I needed to add a loop because the VIExt::http_put_file and VIExt::http_get_file functions periodically fail. That is, if copy_file_to fails, the code sleeps for a few seconds and tries again, up to a maximum of a few tries. From what I can tell, this sort of looping doesn't exist when prepare_vmx() is called. I can wrap that in a Module::code_loop_timeout subroutine, if you would like. 3. When vCenter clones a VM with the CloneVM method, it will silently truncate long vm names. This isn't necessarily a problem as long as that new name finds its way into the database; otherwise, however, when VMX files are generated, the vmdk file pointers will reference incorrect locations. I had solved this by enforcing a maximum length in the web code (i.e. the vcl.image.name table). There are pros and cons to this, though a better approach may be to retrieve the actual name of the vmdk file after a clone operation is performed. This would require having the copy_virtual_disk and move_virtual_disk to return values other than just 1 (or, those methods could update the database themselves). I am not sure which approach you would prefer. I am also unsure of the best way to update the database with this information: would I simply call database_execute(...) and then call $self->data->refresh()? Or is there other code that handles this type of operation? Please advise. Aaron On Apr 25, 2012, at 10:28 AM, Josh Thompson wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > I think we targeted April to get a release out. The number of JIRA issues we > have left is starting to go down a fair amount. I'm almost finished with the > frontend. How's the backend? Are there other things we'd like to do for > this > release such as scripting the install as much as possible? I don't think > we'll be done by the end of April, but I think the first week of May would be > possible. > > Aaron C., Jim, and David - Have you tested your provisioning modules with > recent code from subversion? If not, do you think you can do that in the > next > week or two? > > Josh > - -- > - --- > 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.0.17 (GNU/Linux) > > iEYEARECAAYFAk+YChIACgkQV/LQcNdtPQPsagCdHCZOuT1ZIXxZrB+9EtppUjkc > KJIAn1mxEVtuZ64KEG0I4AwosUo3qT2P > =InjJ > -END PGP SIGNATURE- >
[jira] [Updated] (VCL-505) Dojo is slow to load, especially on pages with many ancillary class files
[
https://issues.apache.org/jira/browse/VCL-505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Coburn updated VCL-505:
-
Attachment: vcl.profile.js
This is an updated profile file, which does not include the custom vcldojo.*
objects, since I did not figure out how to properly include them in one of
these layers. This profile file was used with dojo release 1.6.1
> Dojo is slow to load, especially on pages with many ancillary class files
> -
>
> Key: VCL-505
> URL: https://issues.apache.org/jira/browse/VCL-505
> Project: VCL
> Issue Type: Improvement
> Components: web gui (frontend)
> Reporter: Aaron Coburn
>Assignee: Josh Thompson
>Priority: Minor
> Fix For: 2.3
>
> Attachments: utils.php.patch, vcl.profile.js, vcl.profile.js
>
>
> Dojo has a dynamic loading mechanism with the dojo.require("...") function.
> This is very convenient for developers, but for web users, this requires, in
> some cases, dozens of extra GET requests to load the ancillary javascript
> libraries.
> With this in mind, I would recommend looking at the Dojo custom build
> framework at:
> http://dojotoolkit.org/reference-guide/quickstart/custom-builds.html
> This allows a developer to create custom javascript libraries that contain
> all the needed code for a given 'profile'. I have done this for our
> installation of the VCL, and it results in a dramatic improvement in load
> times for individual pages.
> This change requires changing the .ht-inc/utils.php file. I have attached a
> sample patch (based on version 2.2.1).
> This also requires building a custom dojo environment which can be done by
> first downloading the full dojo SDK, and then creating a vcl 'profile' in
> dojo-release-x.x.x-src/util/buildscripts/profile (i.e. vcl.profile.js). The
> custom files can be generated by issuing the following commands:
> $ cd dojo-release-x.x.x-src/util/buildscripts
> $ ./build.sh profile=vcl action=release
> (I first added the vcldojo files to the dojo directory so that the
> TimeTextBoxEnd class could be included in the package).
> I have also attached the vcl profile I used. The names given to each 'layer'
> correspond to the changes in utils.php.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Dojo library optimization
Josh,
I also recall having an issue with the vcldojo code. I never entirely figured
out how to integrate it into the custom dojo profiles, opting instead to just
keep it separate. As I look at the 2.2.1 code, this only seems to apply to the
{request | new | edit}BlockAllocation modes. In the .ht-inc/utils.php file, I
added a line that would explicitly load js/vcldojo/TimeTextBoxEnd.js in the
getDojoHTML function:
if ($mode != 'blockAllocations'){
$rt .= "\n";
}
These lines would be inserted after dojo/dojo/dojo.js and the relevant
dojo/dojo/dojoCustom.js scripts are loaded.
Hope that helps!
Aaron
--
Aaron Coburn
Systems Administrator and Programmer
Academic Technology Services, Amherst College
acob...@amherst.edu<mailto:acob...@amherst.edu>
On Apr 5, 2012, at 8:50 AM, Josh Thompson wrote:
Aaron,
I've been working on this JIRA issue. I'm having a problem with the custom
vcldojo.* objects. I copied the vcl/js/vcldojo directory to the dojo source
as a sibling directory of dojo, dijit, and dojox, and listed the relative path
to vcldojo at the end of the vcl.profile.js file the same way you did in the
one you attached to the JIRA issue. However, when I load any pages that have
a widget from vcldojo, I'm getting a javascript error that dojo could not load
the widget. Also, it is doing a separate load of the .js file for that widget
even though I can see that the widget was built in to the layer file. Did you
have any issues similar to this? Any ideas?
Thanks,
Josh
On Friday, August 26, 2011 3:47:54 PM you wrote:
Aaron,
Thanks for creating a JIRA issue about it and adding some patches. You're
definitely right about the number of GETs slowing down page loads. I was
planning on creating one dojo include per VCL page in the next release,
though I never created a JIRA issue about it. I did do some work already,
but I like how you structured it a little better.
Thanks,
Josh
On Friday August 26, 2011, Aaron Coburn wrote:
Many parts of the VCL web interface use the Dojo javascript framework,
which has a nice facility for incrementally loading the classes needed
for a particular page through the dojo.require(...) function. On some
pages, however, the number of separate GET requests grows rather large.
This makes the pages much less responsive, especially when a page is
loaded for the first time.
With dojo, it is also possible to create custom 'profiles', which are
groups of dojo classes that are assembled into a single javascript
library. More information about this is available here:
http://dojotoolkit.org/reference-guide/quickstart/custom-builds.html
I assembled about a dozen of these 'profiles' for our VCL installation,
and with some modification to the .ht-inc/utils.php page, this change
has resulted in a dramatic improvement in the loading and rendering of
the vcl web pages.
Is there any thought for moving in this direction for an upcoming
release? I have created a JIRA issue for this at:
https://issues.apache.org/jira/browse/VCL-505
where I have included some more information as well as the code I used
to
implement this in our VCL setup.
Best wishes,
Aaron Coburn
Systems Administrator and Programmer
Academic Technology Services, Amherst College
(413) 542-5451 acob...@amherst.edu<mailto:acob...@amherst.edu>
--
---
Josh Thompson
Systems Programmer
Advanced Computing | VCL Developer
North Carolina State University
josh_thomp...@ncsu.edu<mailto:josh_thomp...@ncsu.edu>
919-515-5323
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.
[jira] [Updated] (VCL-560) cleartext password stored in VMProfile table
[ https://issues.apache.org/jira/browse/VCL-560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Coburn updated VCL-560: - Attachment: vmprofile.alter.sql web.patch managementnode.patch > cleartext password stored in VMProfile table > > > Key: VCL-560 > URL: https://issues.apache.org/jira/browse/VCL-560 > Project: VCL > Issue Type: Bug > Components: database, vcld (backend), web gui (frontend) >Affects Versions: 2.2.1 >Reporter: Aaron Coburn > Labels: security > Attachments: managementnode.patch, vmprofile.alter.sql, web.patch > > > To provide some background, we are setting up a VCL system for several > institutions, using multiple, physically distributed management nodes (each > located at different institutions). Each management node will control its own > VMware infrastructure of one or more hosts while all accessing the central > vcl database. > As you know, each VMhost draws its configuration information from the > `vmprofile` table, including information for accessing that VMhost > infrastructure. For vSphere-based systems, the management node extracts login > credentials from the `username` and `password` fields. The other API modules > do not require the password field. The problem, however, is that the > passwords are stored in cleartext. > Yes, cleartext. > This means that if the VCL is using the vSphere API, anyone from institution > X who has access to the VCL database could easily access the login > credentials for the VM Host(s) at institution Y. The other issue is that > these passwords are being transferred in cleartext between database and > management nodes, so anyone listening in on the wire could also, potentially, > gain access to the VMware infrastructure. Furthermore, while the passwords > are masked in the web UI behind 'password' fields, the ajax call that > populates those fields can easily be inspected in order to get the actual > text. I can see how this isn't such an issue if a VCL system is running > within a single institution inside a single network, but in our case, that is > not the situation. > A compounding issue is that the web UI allows admins to enter the passwords > for VMhost profiles, which means that there would need to be a mechanism for > making sure that the password for the VMprofile at institution X isn't > encrypted using the same key as the password for the corresponding profile at > institution Y. > To solve this, I have written some code that performs asymmetric key > encryption so that the passwords are stored in a more secure format. Attached > are the relevant patch files. > Effectively, what I have done is add three fields to the `vmprofile` table: > rsa_pub: a string containing a public key > rsa_key: the location of the corresponding private key (i.e. > "/etc/vcl/vmhost01.key") > encrypted_passwd: the RSA-encrypted password. (There isn't a strong reason to > have this be a separate field from the existing password field, but > separating the two made it easier to test.) > Next, I added additional input fields in the VMProfile UI for accepting > rsa_pub and rsa_key. I have also updated the javascript code to support this. > If an RSA public key is supplied, the vm.php file will encrypt the incoming > password using the openssl_* functions that come with most distributions of > PHP. The encrypted password is stored in the `encrypted_passwd` field and the > `password` field is set to NULL. This causes the web UI not to show the > masked passwords, which is a behavior that I preferred to have, though others > may prefer something different. The encryption function was put in utils.php > and called encryptDataAsymmetric($data, $public_key) -- it more or less > follows the style of the existing encryptData($data) function. > Finally, vcld needs to be able to decrypt the data, so I added some code to > VCL::utils. First, I expanded the vmhost/vmprofile SQL statement to include > the new rsa_key and encrypted_passwd fields. Then, vcld will check whether a > key exists in the location specified, and if so, it will use that key to > decrypt the password. The decrypted password is then put into the data > structure in the expected location: vmprofile.password > The perl code relies on one additional library: Crypt::OpenSSL::RSA, which > has its own set of dependencies, but these are all available on the EPEL > repository or CPAN. I would add that the Crypt::OpenSSL::RSA library is quite > mature and well maintained. >
[jira] [Created] (VCL-560) cleartext password stored in VMProfile table
cleartext password stored in VMProfile table Key: VCL-560 URL: https://issues.apache.org/jira/browse/VCL-560 Project: VCL Issue Type: Bug Components: database, vcld (backend), web gui (frontend) Affects Versions: 2.2.1 Reporter: Aaron Coburn To provide some background, we are setting up a VCL system for several institutions, using multiple, physically distributed management nodes (each located at different institutions). Each management node will control its own VMware infrastructure of one or more hosts while all accessing the central vcl database. As you know, each VMhost draws its configuration information from the `vmprofile` table, including information for accessing that VMhost infrastructure. For vSphere-based systems, the management node extracts login credentials from the `username` and `password` fields. The other API modules do not require the password field. The problem, however, is that the passwords are stored in cleartext. Yes, cleartext. This means that if the VCL is using the vSphere API, anyone from institution X who has access to the VCL database could easily access the login credentials for the VM Host(s) at institution Y. The other issue is that these passwords are being transferred in cleartext between database and management nodes, so anyone listening in on the wire could also, potentially, gain access to the VMware infrastructure. Furthermore, while the passwords are masked in the web UI behind 'password' fields, the ajax call that populates those fields can easily be inspected in order to get the actual text. I can see how this isn't such an issue if a VCL system is running within a single institution inside a single network, but in our case, that is not the situation. A compounding issue is that the web UI allows admins to enter the passwords for VMhost profiles, which means that there would need to be a mechanism for making sure that the password for the VMprofile at institution X isn't encrypted using the same key as the password for the corresponding profile at institution Y. To solve this, I have written some code that performs asymmetric key encryption so that the passwords are stored in a more secure format. Attached are the relevant patch files. Effectively, what I have done is add three fields to the `vmprofile` table: rsa_pub: a string containing a public key rsa_key: the location of the corresponding private key (i.e. "/etc/vcl/vmhost01.key") encrypted_passwd: the RSA-encrypted password. (There isn't a strong reason to have this be a separate field from the existing password field, but separating the two made it easier to test.) Next, I added additional input fields in the VMProfile UI for accepting rsa_pub and rsa_key. I have also updated the javascript code to support this. If an RSA public key is supplied, the vm.php file will encrypt the incoming password using the openssl_* functions that come with most distributions of PHP. The encrypted password is stored in the `encrypted_passwd` field and the `password` field is set to NULL. This causes the web UI not to show the masked passwords, which is a behavior that I preferred to have, though others may prefer something different. The encryption function was put in utils.php and called encryptDataAsymmetric($data, $public_key) -- it more or less follows the style of the existing encryptData($data) function. Finally, vcld needs to be able to decrypt the data, so I added some code to VCL::utils. First, I expanded the vmhost/vmprofile SQL statement to include the new rsa_key and encrypted_passwd fields. Then, vcld will check whether a key exists in the location specified, and if so, it will use that key to decrypt the password. The decrypted password is then put into the data structure in the expected location: vmprofile.password The perl code relies on one additional library: Crypt::OpenSSL::RSA, which has its own set of dependencies, but these are all available on the EPEL repository or CPAN. I would add that the Crypt::OpenSSL::RSA library is quite mature and well maintained. I wrote this code so that it is entirely optional to encrypt passwords. If an RSA public key is not attached, then no encryption is performed: the password is stored, as before, in cleartext in vmprofile.password. If the private keyfile does not exist on a management node, then no decryption is performed, and the existing value of vmprofile.password is used. I should also add that the encrypted passwords are stored in hexadecimal format, since that is easier to deal with when it comes to storing them in a database. In order to use this code, one will need to generate RSA keys ahead of time like so: $ openssl genrsa -out vmhost.key 1024 $ openssl rsa -in vmhost.key -pubout > vmhost.key.pub (One can generate a larger k
[jira] [Commented] (VCL-497) dedup eppn
[ https://issues.apache.org/jira/browse/VCL-497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13221771#comment-13221771 ] Aaron Coburn commented on VCL-497: -- I asked someone I know at Internet2 (the guys who develop Shibboleth), and he said that, strictly speaking, an application *should* be able to handle a duplicated ePPN. He suggested stripping off everything after a ";". > dedup eppn > -- > > Key: VCL-497 > URL: https://issues.apache.org/jira/browse/VCL-497 > Project: VCL > Issue Type: Improvement > Components: web gui (frontend) >Reporter: Josh Thompson > Fix For: 2.4 > > > The Shibboleth spec allows the eppn to contain duplicates. The code needs to > be updated to handle multiples as well as duplicates in those multiples. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (VCL-497) dedup eppn
[ https://issues.apache.org/jira/browse/VCL-497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13220968#comment-13220968 ] Aaron Coburn commented on VCL-497: -- What do you mean by duplicates? Do you mean multiple values? eppn (eduPersonPrincipalName) is always supposed to be a single, scoped value. It is also supposed to be globally unique. See here for details: http://www.incommon.org/attributesummary.html#eduPersonScoped eduPersonScopedAffiliation can have multiple values, but that is different. In any case, $_SERVER['eppn'] is always supposed to be in this form: user@domain > dedup eppn > -- > > Key: VCL-497 > URL: https://issues.apache.org/jira/browse/VCL-497 > Project: VCL > Issue Type: Improvement > Components: web gui (frontend) >Reporter: Josh Thompson > Fix For: 2.4 > > > The Shibboleth spec allows the eppn to contain duplicates. The code needs to > be updated to handle multiples as well as duplicates in those multiples. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Changing the "e-mail address field" editable
Satoshi, The other issue you will need to consider relates to how users authenticate. If you use LDAP, whenever the updateLDAPUser() method is called, the email field is overwritten with the value received from the LDAP server. The same applies to Shibboleth authentication, though here, updateShibUser() is the method in question. Either way, for every non-local user account, the email address is, by default, overwritten in the database whenever the user logs in. So in addition to userpreferences.php, you will also need to modify the relevant file in .ht-inc/authmethods. Aaron -- Aaron Coburn Systems Administrator and Programmer Academic Technology Services, Amherst College (413) 542-5451 acob...@amherst.edu On Mar 2, 2012, at 8:14 AM, Satoshi KOBAYASHI wrote: > Hello. > > At present, the e-mail address displayed at the "User Preferences" page > is a "read only" field. We are thinking that allowing users to change > the e-mail address by themselves will make it more convenint. > > To do this, we speculate that editing the "userpreferences.php", > to change the e-mail address field editable, and to post it to the database > will work it out. > Please help us if there are anything to consider by making this change. > > > Thank you. > > -- > Satoshi KOBAYASHI > > > >
Re: [jira] [Created] (VCL-543) OSX under ESXi 4.1
This is new with OS X 10.7 (Lion). There are also certain conditions on this. First of all, you need to be running OS X VMs on Apple hardware, and there is a hard limit on the number of virtualized instances that you can run on any machine. Second, the VMs need to be run on a system that is already running Lion. The documents listed in this JIRA issue describe installing VMware ESX as a hypervisor (on Mac Pro hardware) and then running three instances of Lion inside that. I am not sure that entirely conforms to the EULA. My reading of it, at least, is that you need to have an instance of OS X running directly on the hardware. The EULA for Lion states (in section B): B. License from Mac App Store. If you obtained a license for the Apple Software from the Mac App Store, then subject to the terms and conditions of this License and as permitted by the Mac App Store Usage Rules set forth in the App Store Terms and Conditions (http://www.apple.com/legal/itunes/ww/) (“Usage Rules”), you are granted a limited, non-transferable, non-exclusive license: … (iii) to install, use and run up to two (2) additional copies or instances of the Apple Software within virtual operating system environments on each Mac Computer you own or control that is already running the Apple Software. This is further qualified with the following: The grant set forth in Section 2B(iii) above does not permit you to use the virtualized copies or instances of the Apple Software in connection with service bureau, time-sharing, terminal sharing or other similar types of services. This last clause also potentially conflicts with what the VCL is doing, namely "terminal sharing or other similar types of services". Or is there another way to read this? Aaron -- Aaron Coburn Systems Administrator and Programmer Academic Technology Services, Amherst College (413) 542-5451 acob...@amherst.edu On Feb 24, 2012, at 8:29 AM, Mark Gardner wrote: > While I am glad to see OSX supported, I was under the impression that > it was against Apple's license. Am I out of touch? > > Mark > > On Tue, Dec 6, 2011 at 7:44 PM, James O'Dell (Created) (JIRA) > wrote: >> OSX under ESXi 4.1 >> -- >> >> Key: VCL-543 >> URL: https://issues.apache.org/jira/browse/VCL-543 >> Project: VCL >> Issue Type: Improvement >> Components: database, vcld (backend), web gui (frontend) >>Affects Versions: 2.2.1 >>Reporter: James O'Dell >> Fix For: 2.2.1 >> >> >> VCL needs OSX support. These files are my first attempt at doing so. >> >> -- >> This message is automatically generated by JIRA. >> If you think it was sent incorrectly, please contact your JIRA >> administrators: >> https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa >> For more information on JIRA, see: http://www.atlassian.com/software/jira >> >> > > > > -- > Mark Gardner > --
Re: VMware provisioning module for vCenter clusters
ly with
>> the resulting VMs constructed very similarly. Each subroutine in the
>> API modules should do a single simple task. The register_vm
>> subroutine should do only that, not actually define/construct the VM,
>> add devices, or other operations.
>>
>> I'd prefer to add subroutines to the API modules to add devices or
>> make other VM configuration changes, replacing the vmx file generation
>> tasks done by prepare_vmx. There could either be granular subroutines
>> for the different device types or a single subroutine named something
>> like 'vmx_add_device' which accepts somewhat elaborate arguments. It
>> could be called from a new define_vm subroutine in VMware.pm similar
>> to:
>>
>> if ($self->api->can('vmx_add_device')) {
>> $self->api->vmx_add_device('virtual_disk' => {
>> 'vmdk_file_path' => $self->get_vmdk_file_path(),
>> 'adapter_type' => $self->get_vm_disk_adapter_type()
>> }
>> );
>> # Add other devices...
>> }
>> else {
>> $self->prepare_vmx().
>> }
>>
>> I'm not at all familiar with what needs to be done for vCenter. Do
>> you think this would work?
>>
>> Also, I haven't had a chance to dig through all of vCenter.pm but
>> there appears to be some duplicated code. Was everything from
>> vSphere.pm copied into vCenter.pm or are all of the subroutines in
>> vCenter.pm ones which you had to modify? What are the main things you
>> had to change which didn't work in vSphere.pm? I'd like to push the
>> general changes into vSphere.pm and try to keep vCenter.pm small if
>> possible.
>>
>> Thanks,
>> Andy
>>
>>
>> On Tue, Jan 31, 2012 at 10:14 AM, Aaron Coburn wrote:
>>>
>>> On Jan 31, 2012, at 9:31 AM, Sean Dilda wrote:
>>>
>>> On 1/31/12 8:46 AM, Aaron Coburn wrote:
>>>
>>> Sean,
>>>
>>>
>>> You can use the vsphere api to get the file names if you really need
>>>
>>> them.
>>>
>>>
>>> This is true, and that may very well be the better approach. I am not
>>>
>>> entirely happy with the method I described earlier, which relies on my
>>>
>>> own observation of an apparently undocumented behavior of VMware. There
>>>
>>> is, for instance, no guarantee that VMware won't start truncating
>>>
>>> virtual disk filenames at 28 characters at some point in the future.
>>>
>>>
>>> On the other hand, if VMware is allowed to (arbitrarily?) truncate
>>>
>>> values that follow an otherwise fairly strict VCL naming convention,
>>>
>>> there could be negative implications for subsequent revisions of a given
>>>
>>> image. Imagine, for instance, a situation with multiple management nodes
>>>
>>> or at least multiple VM host infrastructures. If one infrastructure
>>>
>>> truncates the imagename value, what happens if that image is revised
>>>
>>> again later in a different VM infrastructure (possibly, even, with a
>>>
>>> different VMware API being used). Would the new imagename be generated
>>>
>>> properly? (This example is not at all hypothetical, given the way we
>>>
>>> have set up our VCL).
>>>
>>>
>>> Another potential problem is that the VCL database enforces unique
>>>
>>> imagename values. The VCL, however, would not be able to enforce this if
>>>
>>> VMware is allowed to truncate these values according to its own opaque
>>>
>>> contrivance. In fact, it is entirely is possible to construct a scenario
>>>
>>> in which different versions of the same base image are assigned
>>>
>>> identical paths in a VMware datastore. Aside from not suiting the
>>>
>>> database schema particularly well, this could, potentially, overwrite
>>>
>>> another revision of the same image stored in the VCL repository path.
>>>
>>>
>>>
>>> I agree completely with the concerns you mentioned. That's why I suggested
>>> the APIs. VMware thinks of itself as the only one managing or caring about
>>> filenames. Thus, I think VCL trying to enforce filenames is going to lead
>>> to nothing but problems. Instead I think it should only care about the VM's
>>> name and let VMware figure out the filena
Re: [Discuss] VCL 2.3 release date
Aaron, My comment relates to module design rather than the mechanics of SVN. The basic issue is that I have a module that works great in our VCL infrastructure, but there are ways in which it could more easily integrate into the overall design of the VMware provisioning module. To describe in brief, the vCenter module is implemented as a subclass of the vSphere_SDK module. Since the VMware module doesn't know a priori which API object to use, it iteratively attempts to connect to a vm host using various existing APIs. When I wrote the vCenter module for our system, I tried to touch the VMware module as little as possible, so I ended up subclassing VMware.pm and modifying the definition of $VSPHERE_SDK_PACKAGE (defined, instead, to load VCL::Module::Provisioning::VMware::vCenter). The better approach, though, (and I would appreciate some feedback on this) would be to add an additional class variable (e.g. $VCENTER_PACKAGE) and modify the initialize subroutine in VMware such that if the vSphere module did not connect, it would try connecting with the vCenter module. If that attempt succeeds, the api object would proceed to use the vCenter module. Does that sound like a reasonable approach? This would assume that the username and password used to access vCenter were not the same as the credentials used to access individual esx hosts. That is true for our setup, but is that something we could reliably trust to be the case in other vm host infrastructures? Also, there are some aspects of the vSphere_SDK module that do not rely on VMware's vSphere API -- notably in how the *.vmx files are generated. The vCenter module follows this approach, since when I wrote the module, I chose to reimplement only what was absolutely necessary to make it work. There has been some discussion on this list on precisely this point. I am certainly interested in moving the vCenter code in that direction, but if the hope is to put the vCenter code into the 2.3 release (i.e. by March), it seems more reasonable to use the code that has over six months of testing time in a production environment. I would be concerned about making significant code changes and adding them to a VCL release without allowing much time to evaluate the changes. Aaron On Feb 16, 2012, at 9:41 AM, Aaron Peeler wrote: > Cool, Thanks Jim and Aaron. > > Aaron, > On packaging it up - not sure I follow. Unless I'm misunderstanding - > you just need to commit the modules to the repo. Did you confirm you > had svn access? If not we missed a step in creating your account. > > Josh is the release manager and will do the release candidate the code > is ready. > > > Andy, Josh, others, when you get a chance also chime in on any > thoughts about the 2.3 release timeline, features, etc. > > Thanks, > Aaron P. > > > > > On Wed, Feb 15, 2012 at 3:33 PM, Aaron Coburn wrote: >> I think a March timeframe sounds reasonable for the vCenter module. >> >> I do have a few questions about how best to package it up; I will be in >> touch about that shortly. >> >> Aaron >> >> >> On Feb 15, 2012, at 11:55 AM, James O'Dell wrote: >> >>> Hi, >>> >>> I've been running the OSX provisioning code for about 6 months, and >>> really haven't had much trouble with it. >>> >>> I'm not sure how well it will run under KVM, though. >>> Getting the EFI bios under KVM is something that I haven't had time to >>> work out, ... yet :) >>> >>> __Jim >>> >>> On 2/15/2012 7:22 AM, Aaron Peeler wrote: >>>> Hi Guys, >>>> >>>> I'd like for us to set a plan/goal for the 2.3 release. >>>> >>>> How does end of March sound? >>>> >>>> My thoughts are we identify which features and jira issues need to be >>>> completed and start the process. >>>> >>>> Features to include: >>>> * I think we want to include Aaron C's work on the vcenter modules. >>>> Aaron how do you feel on this? >>>> * The kvm work Andy has added >>>> * vote on putting back in the esxthin.pm module - one of our community >>>> members was using this heavily but we have no way to test it. >>>> * access methods >>>> * server loads - base line code, more improvements would be developed >>>> this Spr/Sum >>>> * Jim O'Dells work on OSX provisioning. I've looked through the code >>>> and it looks good, but I didn't have a way to test it yet. - Jim your >>>> thoughts? >>>> >>>> >>>> Things we exclude: >>>> - cluster reservations improvements. >>>> - jira issues that require large amounts of work at this time >>>> >>>> >>>> Thoughts? >>>> Aaron >>>> >>> >>> >>> - -- >>> Jim O'Dell >>> Network Analyst >>> California State University Fullerton >>> Email: jod...@fullerton.edu >>> Phone: (657) 278-2256 >> > > > > -- > Aaron Peeler > Program Manager > Virtual Computing Lab > NC State University > > 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.
Re: [Discuss] VCL 2.3 release date
I think a March timeframe sounds reasonable for the vCenter module. I do have a few questions about how best to package it up; I will be in touch about that shortly. Aaron On Feb 15, 2012, at 11:55 AM, James O'Dell wrote: > Hi, > > I've been running the OSX provisioning code for about 6 months, and > really haven't had much trouble with it. > > I'm not sure how well it will run under KVM, though. > Getting the EFI bios under KVM is something that I haven't had time to > work out, ... yet :) > > __Jim > > On 2/15/2012 7:22 AM, Aaron Peeler wrote: > > Hi Guys, > > > > I'd like for us to set a plan/goal for the 2.3 release. > > > > How does end of March sound? > > > > My thoughts are we identify which features and jira issues need to be > > completed and start the process. > > > > Features to include: > > * I think we want to include Aaron C's work on the vcenter modules. > > Aaron how do you feel on this? > > * The kvm work Andy has added > > * vote on putting back in the esxthin.pm module - one of our community > > members was using this heavily but we have no way to test it. > > * access methods > > * server loads - base line code, more improvements would be developed > > this Spr/Sum > > * Jim O'Dells work on OSX provisioning. I've looked through the code > > and it looks good, but I didn't have a way to test it yet. - Jim your > > thoughts? > > > > > > Things we exclude: > > - cluster reservations improvements. > > - jira issues that require large amounts of work at this time > > > > > > Thoughts? > > Aaron > > > > > - -- > Jim O'Dell > Network Analyst > California State University Fullerton > Email: jod...@fullerton.edu > Phone: (657) 278-2256
Re: "icon on the desktop" access to VCL
Josh, One thing you may also want to consider is how you would handle api authentication for institutions that use Shibboleth. There are secure ways to do this, à-la the google 2-step verification or via an embedded browser, but that would involve some additional fields in the database and modification of the web front-end. The main question in my mind would be whether the application would store these access credentials and/or how a user logs out. I don't see this as a problem for users' personal machines, but if someone tried to use this in the context of a pubic or lab computer, I would be very concerned. If, as Art suggested below, the desktop app required users to authenticate and then be timed out after a set period, then what would be the advantage of a desktop app? Especially if a campus already has some type of web-based single sign on in place. In short, what exactly is the goal in developing a desktop app? If the goal is to bypass the standard VCL website and simplify access, you can use the existing API to do that. I have written several web-based "alternate interfaces" for our VCL that function well, including one that integrates with our campus' learning management system. They are easy to write and the developer has full control over how they look -- that would be harder to accomplish with a desktop application. The existing API is certainly more limited in its range of functions when compared to the full web site. On the other hand, it is capable of making and managing reservations, which constitute the vast majority of users' (esp. students') interactions with the VCL. You can see some screenshots here: https://vcl.ats.amherst.edu/remote_access/ On the other hand, if the goal is to eliminate the somewhat awkward transition between the VCL website and an active RDP connection, there are ways to deal with that, too. With the use of protocol handlers and a little bit of custom application development for Windows, we have a working "one-click logon" solution that works on all of the major browser-OS combinations (IE, FF, Safari, Chrome; Win7, WinXP, OS X, Ubuntu). And this pairs nicely with the remote interfaces mentioned above, making it really simple for users to connect. Aaron -- Aaron Coburn Systems Administrator and Programmer Academic Technology Services, Amherst College (413) 542-5451 acob...@amherst.edu On Feb 8, 2012, at 2:08 PM, Art Vandenberg wrote: > Georgia State is likely interested in this IF it doesn't reduce security. I > presume icon would be clickable and then one VIOLA, logged in? If so, there > is presumably no login per se. Perhaps some time-out on the ICON would be > valuable then - e.g. you have "x minutes" to click or else (something > happens... goes away? expires? prompts for PW after all?) Maybe recommended > only where there is at least some login (to VCL menu at least) so there is a > reasonable accountability? > > > I am going to send this to our engineers and ask for their input (I think the > read the posts, but will be direct.) > > Art > > > On Feb 8, 2012, at 11:56 AM, Josh Thompson wrote: > >> I've been hearing interest in an "icon on the desktop" type of access to >> VCL. The idea being that you could have some kind of broker script/app that >> can be run which will interact with the VCL API to create a VCL >> reservation, wait on it to be deployed, and then connect to the reserved >> system (ideally without requiring the user to log in to the reserved >> system). That app could then just be launched through an icon to gain >> access to a VCL provisioned system. >> >> Several years ago, I wrote something along the lines of this in python/tk. >> That was more of a proof of concept and would need a good bit of work to be >> useful to others. >> >> I'm starting this thread to start gathering information on who is >> interested in this idea and what requirements you would have for it. I'd >> also like to know if anyone would be interested in helping with the >> development of it. >> >> So, if you have any interest in this, please reply to this thread with >> -requirements you would have >> -how you would envision it to work >> -any interest in development of it >> >> Thanks, >> Josh >> --- >> Josh Thompson >> VCL Developer >> North Carolina State University > > Art Vandenberg > Account Manager/Research Function > Customer Relations, IS&T > Information Systems & Technology > Georgia State University > avandenb...@gsu.edu > +1 404 413 4743 > MS Information & Computer Science, Georgia Tech > MVA Painting & Drawing, Georgia State > Web page: http://www.gsu.edu/ist/acs/25735.html >
Re: vcld test script
Has there been any thought about the installation procedure of the perl code
for VCL?
The current approach is to manually rename the management node directory to
/usr/local/vcl
Wouldn't it be better to use a standard Makefile.PL for this? This would allow
the modules to avoid the 'use lib "$FindBin::Bin/..."' constructs, because the
modules would be in perl's @INC path. Furthermore, there are a number of places
where the installation directory is hard-coded (VCL::Module::OS::Windows) --
that could all be pushed to a configuration file, written by the Makefile.PL
script.
It would also allow the vcld script to be installed in a more standard location
(e.g. /usr/local/bin)
Plus, this would make the code consistent with other CPAN modules. If there was
interest (some time in the future) to make these libraries available on CPAN,
these changes would all be necessary.
Furthermore, this would make it much easier to build and run a test suite for
the perl code -- ExtUtils already has a structure for supporting this. I have
attached a sample Makefile.PL
use warnings;
use strict;
use ExtUtils::MakeMaker;
my @prog = qw/vcld gen-node-key.sh/;
WriteMakefile(
NAME => 'VCL',
ABSTRACT => 'Virtual Computing Lab',
LICENSE => 'Apache',
EXE_FILES=> [ map "bin/$_", @prog ],
VERSION_FROM => 'lib/VCL/utils.pm',
PREREQ_PM=> { 'Digest::SHA1' => 0,
'DBI' => 0,
'File::Temp' => 0,
'Getopt::Long' => 0,
'HTTP::Headers' => 0,
'IO::File' => 0,
'List::Util' => 0,
'Mail::Mailer' => 0,
'Net::Ping' => 0,
'Object::InsideOut' => 0,
'RPC::XML::Client' => 0,
'Shell' => 0,
'Storable' => 0,
'Text::Wrap' => 0,
'Time::Local' => 0,
'YAML' => 0 },
MIN_PERL_VERSION => 5.008000,
META_MERGE => {
recommends => { 'VMware' => 0 },
resources => {
repository => 'https://svn.apache.org/repos/asf/incubator/vcl',
MailingList => 'mailto:vcl-dev@incubator.apache.org'
}
},
AUTHOR => 'Virtual Computing Lab',
clean => { FILES => join(" ", map "bin/$_", grep /^[A-Z\.]+$/, @prog) }
);
This is just a stub, but with a little more work, it could be used to configure
/etc/vcl/vcld.conf and run the various tests that have been listed below.
Aaron
--
Aaron Coburn
Systems Administrator and Programmer
Academic Technology Services, Amherst College
(413) 542-5451 acob...@amherst.edu
On Jan 13, 2012, at 11:41 AM, Andy Kurth wrote:
> I like the idea. Other tests which would be useful:
>
> -check VM host license expiration dates
> -check if the network names defined in the VM profile are available on
> the VM hosts
> -check amount of space available for VM host datastores, management
> node repository, and management node volume where vcld.log is being
> written
> -make sure required attributes are defined for VMs such as MAC
> addresses if they are not auto-generated
> -check if time is sychronized on VM hosts, management node, and the
> database server
> -send a test sysadmin email message
>
> The architecture of 'vcld -setup' hasn't been discussed on this list
> so now is a good time to begin. The idea is for vcld to handle all of
> the details so that any module just needs to implement a subroutine
> named 'setup' and it automatically gets added to the menu. This
> allows any module to contain options specific to itself but results in
> a somewhat clunky menu system.
>
> It would be good to have a single menu option where all of the tests
> appear yet still allow each module to implement it's own test code.
> In order to do this, the setup_management_node sub in vcld will need
> to be extended. I had thought about adding something like this in the
> past but never completed it. I was thinking of adding code to vcld to
> look for modules which implement a 'setup_check' subroutine (the same
> way it looks for 'setup') and then put all of these under a single
> menu option.
>
> There are a few bits and pieces to look at in the current code. There
> is a setup_check subroutine in Windows.pm. It simply gets calle
Re: VCL block alloc, PERL module issue update
Oh. It looks like RPC-XML is not installed. You can verify that by using this command: perl -MRPC::XML -e "print 'have a nice day'" If you get errors, the module isn't installed. If the script seems friendly, then the module is installed. If the module is not installed, download it from here: http://search.cpan.org/dist/RPC-XML/ unpack it and install it like so: perl Makefile.PL make && make test sudo make install Then try the command again that I listed above. On Jan 31, 2012, at 4:42 PM, Mike Haudenschild wrote: > Hi Aaron, > > I get the following errors running install_perl_libs from trunk, on CentOS > 5.7 fully updated: > > *No package perl-CPAN available.* > *WARNING: unexpected output returned while installing Linux package: > 'perl-CPAN'* > *this has happened since my first install, but doesn't seem to be a problem > since cpan is already installed in CentOS base > > *No package perl-RPC-XML available.* > *WARNING: unexpected output returned while installing Linux package: > 'perl-RPC-XML'* > *this has also happened since my first install, but I've never been able to > resolve this. I thought perhaps the CPAN commands issued at the end of the > install script installed RPC::XML from CPAN...? > > All of the PERL module installs throw: > *Unknown command 'notest'. Type ? for help.* > > Two PERL modules fail to install: > > *Attempting to install Perl module using CPAN: 'Object::InsideOut'* > *Unknown command 'notest'. Type ? for help.* > *checking if Object::InsideOut Perl module is installed...* > *Perl module Object::InsideOut appears to be installed but the version > could not be determined* > *command: perl -e "eval \"use Object::InsideOut\"; print > \$Object::InsideOut::VERSION" 2>&1* > *output:* > *ERROR: failed to install Perl module: 'Object::InsideOut'* > > > *Attempting to install Perl module using CPAN: 'RPC::XML'* > *Unknown command 'notest'. Type ? for help.* > *checking if RPC::XML Perl module is installed...* > *Perl module RPC::XML appears to be installed but the version could not be > determined* > *command: perl -e "eval \"use RPC::XML\"; print \$RPC::XML::VERSION" 2>&1* > *output:* > *ERROR: failed to install Perl module: 'RPC::XML'* > > Thanks!! > Mike > > -- > *Mike Haudenschild* > Education Systems Manager > Longsight Group > (740) 599-5005 x809 > m...@longsight.com > www.longsight.com > > > > On Tue, Jan 31, 2012 at 14:43, Aaron Peeler wrote: > >> Hi Mike, >> >> Apologies for not responding on this. >> >> Are you still seeing this issue with your block allocations? >> >> If so you could try to use the latest install_perl_libs.pl script >> >> https://svn.apache.org/repos/asf/incubator/vcl/trunk/managementnode/bin/install_perl_libs.pl >> >> Aaron >> >> On Wed, Jan 25, 2012 at 6:40 PM, Mike Haudenschild >> wrote: >>> Dev team, >>> >>> I would very much appreciate guidance on whether I should try defining >> (or >>> bypassing) the SSL cert variables in the PERL scripts, or if I should/can >>> downgrade the applicable PERL modules to older known-working versions to >>> workaround this issue altogether. >>> >>> The log was telling me that LWP::Protocol::https was required, and it's >> not >>> installed by the install_perl_libs script (because LWP::Protocol::https >> was >>> recently split out from libwww-perl?). Once installed, however, I get >>> static as shown in the logs below. >>> >>> I'm dead in the water with block allocations. Thanks very much for any >>> help. >>> >>> Regards, >>> Mike >>> >>> >>> On Tue, Jan 24, 2012 at 21:00, Mike Haudenschild >> wrote: >>> Good evening, I apologize for the numerous emails, but as I continue working through this something new popped up: I managed to get LWP::Protocol::https to install by first updating Net::SSLLeay with CPAN. However, when making a block allocation I now get this in the log: |4978|blockrequest| CRITICAL |4978|blockrequest| 2012-01-24 20 >> :53:45|4978|blockrequest|vcld:die_handler(636)|Can't locate object method "type" via package "RPC::XML::Client::send_request: HTTP server error:* Can't connect to vclserver:443< >> http://urichmond.longsight.com:443>(certificate verify failed) *" (perhaps you forgot to load "RPC::XML::Client::send_request: HTTP server error: Can't connect to server.domain.com:443 (certificate >> verify failed)"?) at /usr/local/vcl/bin/../lib/VCL/utils.pm line 9121. |4978|blockrequest| ( 0) vcld, die_handler (line: 636) |4978|blockrequest| (-1) utils.pm, xmlrpc_call (line: 9121) |4978|blockrequest| (-2) blockrequest.pm, process_block_time (line: >> 373) |4978|blockrequest| (-3) blockrequest.pm, process (line: 193) |4978|blockrequest| (-4) vcld, make_new_child (line: 568) |4978|blockrequest| (-5) vcld, main (line: 448) 2012-01-24 20 >> :53:45|4978|blockrequest|State.pm:DESTROY(829)|VCL::blockrequest destructor called, a
Re: VCL block alloc, PERL module issue update
Not sure what you mean by "hand install". That should have been installed as a
part of perl-libwww-perl. Try:
yum info perl-libwww-perl
RPC-XML will require using either cpan or the standard:
perl Makefile.PL
make && make test
make install
I would recommend NOT using cpan, since it can create hard-to-debug conflicts
with the CentOS libraries, especially if they are installed in the wrong order.
There may also be a networking issue involved. Can you access the vcl website
correctly from the management node?
curl -L https://your website.org
If those check out, try accessing the XML-RPC interface directly through a
little external perl script (naturally, from the management node). Here's an
example:
#!/usr/bin/perl -w
use strict;
use RPC::XML::Client;
use Term::ReadKey;
my $VCL_LOCATION = 'https://YOUR WEBSITE?mode=xmlrpccall';
$|++;
print "Username: ";
chomp(my $username = <>);
print "Password: ";
ReadMode 2;
chomp(my $password = <>);
ReadMode 0;
print "\n";
my $client = RPC::XML::Client->new($VCL_LOCATION);
$client->fault_handler(
sub {
print "XML-RPC Fault: ", $_[0]->value->{'faultString'}, "\n";
exit;
});
$client->error_handler(
sub {
print "XML-RPC Error: ", $_[0]->value->{'errorString'}, "\n";
exit;
});
$client->useragent->default_header('X-User' => $username);
$client->useragent->default_header('X-Pass' => $password);
$client->useragent->default_header('X-APIVERSION' => 2);
print $_->value->{'name'}, "\n" foreach
@{$client->send_request(("XMLRPCgetImages"))};
Aaron
On Jan 31, 2012, at 3:23 PM, Mike Haudenschild wrote:
> Hi Aaron,
>
> I really appreciate your response -- starting to sweat bullets on this one.
> Still seeing the problem. It starts out as:
>
> |3425|blockrequest| CRITICAL
> |3425|blockrequest| 2012-01-31
> 10:45:07|3425|blockrequest|vcld:die_handler(636)|Can't locate object method
> "type" via package "RPC::XML::Client::send_request: HTTP server error:
> Protocol scheme 'https' is not supported (LWP::Protocol::https not
> installed)" (perhaps you forgot to load "RPC::XML::Client::send_request:
> HTTP server error: Protocol scheme 'https' is not supported
> (LWP::Protocol::https not installed)"?) at /usr/local/vcl/bin/../lib/VCL/
> utils.pm line 9121.
> |3425|blockrequest| ( 0) vcld, die_handler (line: 636)
> |3425|blockrequest| (-1) utils.pm, xmlrpc_call (line: 9121)
> |3425|blockrequest| (-2) blockrequest.pm, process_block_time (line: 373)
> |3425|blockrequest| (-3) blockrequest.pm, process (line: 193)
> |3425|blockrequest| (-4) vcld, make_new_child (line: 568)
> |3425|blockrequest| (-5) vcld, main (line: 448)
>
> And if I hand-install LWP::Protocol::https, it becomes:
>
> |5745|blockrequest| CRITICAL
> |5745|blockrequest| 2012-01-31
> 11:24:30|5745|blockrequest|vcld:die_handler(636)|Can't locate object method
> "type" via package "RPC::XML::Client::send_request: HTTP server error:
> Can't connect to urichmond.longsight.com:443 (certificate verify failed)"
> (perhaps you forgot to load "RPC::XML::Client::send_request: HTTP server
> error: Can't connect to urichmond.longsight.com:443 (certificate verify
> failed)"?) at /usr/local/vcl/bin/../lib/VCL/utils.pm line 9121.
> |5745|blockrequest| ( 0) vcld, die_handler (line: 636)
> |5745|blockrequest| (-1) utils.pm, xmlrpc_call (line: 9121)
> |5745|blockrequest| (-2) blockrequest.pm, process_block_time (line: 373)
> |5745|blockrequest| (-3) blockrequest.pm, process (line: 193)
> |5745|blockrequest| (-4) vcld, make_new_child (line: 568)
> |5745|blockrequest| (-5) vcld, main (line: 448)
>
> I have been using the install_perl_libs.pl from the 2.2.1 distro -- I will
> bring up a clean OS and try this. I've been using CentOS 5.7 -- is 5.x
> still the most appropriate version?
>
> Thanks!
> Mike
> --
> *Mike Haudenschild*
> Education Systems Manager
> Longsight Group
> (740) 599-5005 x809
> m...@longsight.com
> www.longsight.com
>
>
>
> On Tue, Jan 31, 2012 at 14:43, Aaron Peeler wrote:
>
>> Hi Mike,
>>
>> Apologies for not responding on this.
>>
>> Are you still seeing this issue with your block allocations?
>>
>> If so you could try to use the latest install_perl_libs.pl script
>>
>> https://svn.apache.org/repos/asf/incubator/vcl/trunk/managementnode/bin/install_perl_libs.pl
>>
>> Aaron
>>
>> On Wed, Jan 25, 2012 at 6:40 PM, Mike Haudenschild
>> wrote:
>>> Dev team,
>>>
>>> I would very much appreciate guidance on whether I should try defining
>> (or
>>> bypassing) the SSL cert variables in the PERL scripts, or if I should/can
>>> downgrade the applicable PERL modules to older known-working versions to
>>> workaround this issue altogether.
>>>
>>> The log was telling me that LWP::Protocol::https was required, and it's
>> not
>>> installed by the install_perl_libs script (because LWP::Protocol::https
>> was
>>> recently split out from libwww-perl?). Once i
Re: VMware provisioning module for vCenter clusters
On Jan 31, 2012, at 9:31 AM, Sean Dilda wrote:
> On 1/31/12 8:46 AM, Aaron Coburn wrote:
>> Sean,
>>
>>> You can use the vsphere api to get the file names if you really need
>>> them.
>>
>> This is true, and that may very well be the better approach. I am not
>> entirely happy with the method I described earlier, which relies on my
>> own observation of an apparently undocumented behavior of VMware. There
>> is, for instance, no guarantee that VMware won't start truncating
>> virtual disk filenames at 28 characters at some point in the future.
>>
>> On the other hand, if VMware is allowed to (arbitrarily?) truncate
>> values that follow an otherwise fairly strict VCL naming convention,
>> there could be negative implications for subsequent revisions of a given
>> image. Imagine, for instance, a situation with multiple management nodes
>> or at least multiple VM host infrastructures. If one infrastructure
>> truncates the imagename value, what happens if that image is revised
>> again later in a different VM infrastructure (possibly, even, with a
>> different VMware API being used). Would the new imagename be generated
>> properly? (This example is not at all hypothetical, given the way we
>> have set up our VCL).
>>
>> Another potential problem is that the VCL database enforces unique
>> imagename values. The VCL, however, would not be able to enforce this if
>> VMware is allowed to truncate these values according to its own opaque
>> contrivance. In fact, it is entirely is possible to construct a scenario
>> in which different versions of the same base image are assigned
>> identical paths in a VMware datastore. Aside from not suiting the
>> database schema particularly well, this could, potentially, overwrite
>> another revision of the same image stored in the VCL repository path.
>>
>
> I agree completely with the concerns you mentioned. That's why I suggested
> the APIs. VMware thinks of itself as the only one managing or caring about
> filenames. Thus, I think VCL trying to enforce filenames is going to lead to
> nothing but problems. Instead I think it should only care about the VM's
> name and let VMware figure out the filenames.
I, too, think this approach would be the best for a vCenter-based
infrastructure -- that is, a setup where the VCL keeps track of the names of
the virtual disks, but doesn't enforce a particular format. What I don't know
is what implications that would have on a VMware setup that uses the VIM_SSH or
VIX_API modules -- code with which I am almost entirely unfamiliar. I also
don't know how this would affect how images are shared using the image library
features of the VCL. We are moving toward a multi-node, physically distributed
architecture using a shared image library, but we are not there yet, so I am
only vaguely aware of how this is implemented. Perhaps someone who uses the
image library to share images between management nodes could chime in?
>>> Why does vcl write its own vmx instead of using the apis? vSphere
>>> expects programs to use the apis, not to hand craft files.
>>
>> I completely agree. I must admit that, when I wrote the vCenter
>> provisioning module, I tried to use as much existing VCL code as
>> possible. Rather than reimplementing everything to use vSphere managed
>> objects, I rewrote only what appeared to be necessary. So for example,
>> in VMWare.pm, the 'load' subroutine calls 'prepare_vmx', which generates
>> a vmx text file on the management node. This file is then transferred
>> via VIExt::http_put_file into the VMware infrastructure. While I managed
>> to make this sequence of commands work in the context of vCenter, I
>> agree that it would be far better to implement this differently for a
>> vCenter provisioning module.
>>
>> Within the context of the current VMware module design, the
>> communication with the VM host is expected to occur by means of the API
>> object (i.e. $self->{api}). So for instance, the creation of the virtual
>> machine via vCenter would logically occur when
>> $self->api->vm_register(…) is called. The call to $self->prepare_vmx in
>> the preceding lines would be superfluous, and there would be no need for
>> that method to write and then transfer a vmx file to the VM host
>> infrastructure. In short, there would need to be some way for the
>> vCenter API to circumvent that sequence of commands.
>>
>> Since all the VMware API modules inherit from the base VMware class,
>> there could be a new method, such as 'require_prepare_vmx', for which
>&g
Re: VMware provisioning module for vCenter clusters
Sean,
> You can use the vsphere api to get the file names if you really need them.
This is true, and that may very well be the better approach. I am not entirely
happy with the method I described earlier, which relies on my own observation
of an apparently undocumented behavior of VMware. There is, for instance, no
guarantee that VMware won't start truncating virtual disk filenames at 28
characters at some point in the future.
On the other hand, if VMware is allowed to (arbitrarily?) truncate values that
follow an otherwise fairly strict VCL naming convention, there could be
negative implications for subsequent revisions of a given image. Imagine, for
instance, a situation with multiple management nodes or at least multiple VM
host infrastructures. If one infrastructure truncates the imagename value, what
happens if that image is revised again later in a different VM infrastructure
(possibly, even, with a different VMware API being used). Would the new
imagename be generated properly? (This example is not at all hypothetical,
given the way we have set up our VCL).
Another potential problem is that the VCL database enforces unique imagename
values. The VCL, however, would not be able to enforce this if VMware is
allowed to truncate these values according to its own opaque contrivance. In
fact, it is entirely is possible to construct a scenario in which different
versions of the same base image are assigned identical paths in a VMware
datastore. Aside from not suiting the database schema particularly well, this
could, potentially, overwrite another revision of the same image stored in the
VCL repository path.
> Why does vcl write its own vmx instead of using the apis? vSphere expects
> programs to use the apis, not to hand craft files.
I completely agree. I must admit that, when I wrote the vCenter provisioning
module, I tried to use as much existing VCL code as possible. Rather than
reimplementing everything to use vSphere managed objects, I rewrote only what
appeared to be necessary. So for example, in VMWare.pm, the 'load' subroutine
calls 'prepare_vmx', which generates a vmx text file on the management node.
This file is then transferred via VIExt::http_put_file into the VMware
infrastructure. While I managed to make this sequence of commands work in the
context of vCenter, I agree that it would be far better to implement this
differently for a vCenter provisioning module.
Within the context of the current VMware module design, the communication with
the VM host is expected to occur by means of the API object (i.e.
$self->{api}). So for instance, the creation of the virtual machine via vCenter
would logically occur when $self->api->vm_register(…) is called. The call to
$self->prepare_vmx in the preceding lines would be superfluous, and there would
be no need for that method to write and then transfer a vmx file to the VM host
infrastructure. In short, there would need to be some way for the vCenter API
to circumvent that sequence of commands.
Since all the VMware API modules inherit from the base VMware class, there
could be a new method, such as 'require_prepare_vmx', for which the VMware
class provides a simple default implementation:
sub require_prepare_vmx {
return 1;
}
Then, the lines,
# Generate the .vmx file
if (!$self->prepare_vmx()) {
notify($ERRORS{'WARNING'}, 0, "failed to prepare vmx file for
$computer_name on VM host: $vmhost_name");
return;
}
could be enclosed by a conditional block:
if ($self->api->require_prepare_vmx){
# Generate the .vmx file
if (!$self->prepare_vmx()) {
notify($ERRORS{'WARNING'}, 0, "failed to prepare vmx file for
$computer_name on VM host: $vmhost_name");
return;
}
}
which would provide the vCenter module the hooks it needs in order to skip this
step entirely.
Andy, how would this fit into the current design of the VMware module?
Aaron
> When I wrote Duke's provisioning module to work with vCenter I found it much
> easier to use the apis instead of going through the extra work to get a
> custom vmx created/uploaded/etc.
>
> Aaron Coburn wrote:
>
>> Andy, I can certainly make the initial commit of the module.
>>
>> An interesting problem I have had with this module, however, is that when I
>> clone a VM (which is the only way to move a virtual disk using the vSphere
>> API while preserving thin provisioning), VMWare would silently truncate the
>> name and enclosing directory of the virtual disk -- though only if the
>> basename of the VM is longer than 29 characters. The actual name of the VM
>> can still be up to 80 characters, but the location of the virtual disk, it
>> appears, cannot. And since the VCL crafts its own *.VMX files,
Re: VMware provisioning module for vCenter clusters
Andy, I can certainly make the initial commit of the module. An interesting problem I have had with this module, however, is that when I clone a VM (which is the only way to move a virtual disk using the vSphere API while preserving thin provisioning), VMWare would silently truncate the name and enclosing directory of the virtual disk -- though only if the basename of the VM is longer than 29 characters. The actual name of the VM can still be up to 80 characters, but the location of the virtual disk, it appears, cannot. And since the VCL crafts its own *.VMX files, it needs to know precisely where to find the *.VMDKs. For example, a virtual disk with this name: vmwarewinxp-WindowsNoApps82-v3 (basename has 30 chars) would be saved in this location: vmwarewinxp-WindowsNoApps82-v/vmwarewinxp-WindowsNoApps82-v.vmdk As another example, vmwarewin7-WindowsNoApps52-v0 would not have a problem until it hit version 10 (basename has 29 chars), at which point it would be put in this location: vmwarewin7-WindowsNoApps52-v1_X/vmwarewin7-WindowsNoApps52-v1_X.vmdk (where X would be some number that VMware appends to the virtual disk if version1 is still available on the datastore -- X will increment on subsequent attempts -- note that the basename is now more than 29 total characters) With the VCL naming conventions (ostype-imagenameID-version), it is, of course, easy to exceed the 29-character limit. I was unsuccessful in locating any documentation from VMware about this. The work-around, though, was to add a few lines in the web code to keep the value of vcl.revision.imagename limited to 29 chars. Clearly, it is necessary to retain the version suffix as well as the imageID, so the code pulls apart the imagename clauses, shortens the middle clause and reassembles them into a 29-character-or-less string. Similar code would need to be added to the "-setup" part of vcld. As you know, this imagename value is never actually seen by a user, so I felt at some liberty in modifying how it is generated. Does that seem like a reasonable tact? Aaron On Jan 30, 2012, at 2:36 PM, Andy Kurth wrote: > Hi Aaron, > How would you like to proceed with your vCenter modules now that > you're a committer? You can make the initial commit if you're > comfortable with it. If not, I now have access to a vCenter license > and can incorporate it into the current code in trunk and make the > initial commit. There have been some minor changes to vSphere.pm so > some changes may be necessary. > > Thanks, > Andy > > On Fri, Aug 19, 2011 at 10:01 AM, Aaron Coburn wrote: >> Hi, Andy, >> thanks for the details on where the VMware module is headed. I am interested >> in becoming a committer for the project, though having my institution sign >> off on the Apache license will require a bit of, shall we say, process. I'll >> be in touch about that, though. >> >> Aaron >> >> >> >> On Aug 17, 2011, at 8:52 PM, Andy Kurth wrote: >> >>> This is wonderful. Thank You. I will try to incorporate it over the >>> next few weeks. For anyone interested, the Jira issue is: >>> https://issues.apache.org/jira/browse/VCL-499 >>> >>> Also, I committed your improvements in VCL-470 and VCL-471 on 8/4. >>> >>> I'd suggest working off of trunk in Subversion and svn updating it >>> regularly if you aren't already doing so. I've made some changes to >>> the VMware code over the past few weeks. The vSphere.pm module has >>> been improved to execute much faster. Rather than calling the VMware >>> API every time something such as a datastore object is needed, it is >>> only called once per object and this reference is then stored in the >>> vSphere.pm object for later use. It will probably be easier to >>> incorporate your changes because of this. All calls to get_host_view >>> are funneled through a single subroutine. >>> >>> Also, the method of handling vmdk's has changed after being inspired >>> by ideas shared by Dr. Masoud Sadjadi from Florida International >>> University at the VCL bootcamp last month. Josh Thompson did some >>> research and then I incorporated the findings. It is no longer >>> necessary to create an entire copy of the vmdk for imaging and >>> long-term reservations. All VMs are now configured to use the vmdk in >>> persistent mode instead of independent-persistent or >>> independent-nonpersistent mode. Before a VM is powered on a snapshot >>> is now taken. This causes the VM to write changes to a delta file in >>> the directory where the vmx is located and the master/golden vmdk >>> isn't altered. If
vcld test script
Hi, Guys, The web front-end to the VCL has a "testsetup.php" script that tests a variety of server settings so that the web code is easier to install. I am wondering if there might be interest in building a similar facility into the vcld -setup script. It seems that many of the questions posed on this (and the users') list relate to misconfigured networks and/or provisioning module components. Clearly, the vcld logfile captures all of this, but even that is often turned over to the list for interpretation. This could be a sort of 'dry run' image capture. So here is a stab at what might be useful for such a script to check. My list will be biased heavily in favor of the VMware provisioning modules, because that's what we use in our installation. And I am assuming that the output would be something easy to understand. Network: 1. can vcld get an IP address from a vmhost 'short name' 2. can vcld get an IP address from a given computer 'short name' 3. can vcld reach to the running VM(s) 4. can vcld reach to the VM host 5. can vcld transfer a file to/from the vm host 6. if the image library is enabled, is that accessible Computer: 1. is cygwin installed and sshd running (for Windows) 2. can vcld login successfully 3. does the computer have network access 4. do the computer's MAC addresses match what is expected in the database VM Host: 1. can vcld login to the vm host 2. are the paths listed in vmprofile available in the vmhost infrastructure 3. are certain utilities and/or commands available to vcld from inside the vmhost (i.e. copy virtual disk, create a vm, etc.) etc, etc. Thoughts? Aaron -- Aaron Coburn Systems Administrator and Programmer Academic Technology Services, Amherst College (413) 542-5451 acob...@amherst.edu
Re: VCL andVMWare licensing/load balancing
Mike, Our approach to load balancing is to put all of our VMs inside a vCenter cluster with dynamic resource scheduling enabled -- this allows vmware to move VMs around to balance the load. We can then have an arbitrary number of physical servers, but to the VCL it looks like a single vmhost. The downside of this approach is that you need to purchase VMware's enterprise license. As another precondition for this, your vmhosts can't use local storage for the datastores: they must use a SAN. We also had to write our own provisioning module to get this to work, but so far it is working very well. Aaron -- Aaron Coburn Systems Administrator and Programmer Academic Technology Services, Amherst College (413) 542-5451 acob...@amherst.edu On Dec 8, 2011, at 4:05 PM, Mike Haudenschild wrote: > Hello to all. I've been tasked with building out and managing a VCL > implementation that will utilize VMWare ESXi 4.1 hypervisors across 5 > separate servers. I have trolled the existing documentation and listserv > archive, but I have two burning questions: > > 1. I've read in another thread that VCL doesn't have load balancing > capabilities per se as part of the scheduler. How does VCL equalize the > load of virtual machines across several hypervisors? > > 2. I've found that the "free" VMWare hypervisor 4.1 license caps out at one > physical processor (with 6 cores). Are most folks running a non-free VMWare > license alongside VCL? > > I greatly appreciate any assistance that current VCL users and the dev team > can provide! > > Regards, > Mike > > -- > *Mike Haudenschild* > Education Systems Manager > Longsight Group > (740) 599-5005 x809 > m...@longsight.com > www.longsight.com
Affiliation names with Shibboleth
Hello, I have configured our VCL instance to support five different affiliations (in addition to Local and Global), each of which uses Shibboleth to authenticate. Everything works smoothly, but I'm wondering why the default configuration removes the .edu from the corresponding Shibboleth attribute (eppn) in order to construct the affiliation name? (See around line 113-116 in shibauth/index.php) The result is that group affiliation lists look like this: user1@AMHERST user2@MTHOLYOKE user3@SMITH etc. Similarly, groups might look like this: admin@AMHERST chemistry@HAMPSHIRE math@SMITH math@UMASS etc. Was the intention simply to distinguish the user and group lists from actual email addresses? Clearly, the VCL user/group name + affiliation would not always map cleanly to a real email address, but I was wondering if there was any other reason for this choice. Thanks, Aaron Coburn -- Aaron Coburn Systems Administrator and Programmer Academic Technology Services, Amherst College (413) 542-5451 acob...@amherst.edu
Dojo library optimization
Many parts of the VCL web interface use the Dojo javascript framework, which has a nice facility for incrementally loading the classes needed for a particular page through the dojo.require(...) function. On some pages, however, the number of separate GET requests grows rather large. This makes the pages much less responsive, especially when a page is loaded for the first time. With dojo, it is also possible to create custom 'profiles', which are groups of dojo classes that are assembled into a single javascript library. More information about this is available here: http://dojotoolkit.org/reference-guide/quickstart/custom-builds.html I assembled about a dozen of these 'profiles' for our VCL installation, and with some modification to the .ht-inc/utils.php page, this change has resulted in a dramatic improvement in the loading and rendering of the vcl web pages. Is there any thought for moving in this direction for an upcoming release? I have created a JIRA issue for this at: https://issues.apache.org/jira/browse/VCL-505 where I have included some more information as well as the code I used to implement this in our VCL setup. Best wishes, Aaron Coburn Systems Administrator and Programmer Academic Technology Services, Amherst College (413) 542-5451 acob...@amherst.edu
VMware provisioning module for vCenter clusters
Hello, In our VCL implementation at Amherst College, we are using a VMware cluster for our virtual machine infrastructure. Because we wanted to allow VMs to float between physical hosts according to how VMware prefers to balance resource use (VMware calls this distributed resource scheduling), I wanted to access the cluster as a single datacenter through the vCenter interface. From VCL's perspective, this allows me to put all of my virtual computers on a single VM Host, when in reality each of those VMs is located on one of any number of physical machines that the VCL can remain blithely ignorant about. The vSphere_SDK package, however, requires that vcld access a physical host directly, so I wrote a new provisioning module called VMware::vCenter. This module is a subclass of the vSphere_SDK package and works with version 2.2.1 of the VCL. The new module reimplements the vSphere_SDK subroutines that are incompatible with a datacenter-based connection, primarily anything that calls the VIExt::get_host_view() method or tries to copy or move virtual disks to new locations. There are a few other changes that are explained in the JIRA issue I created for this. I have included the relevant code in JIRA, but let me know if there is anything else I should do to help this along. Best regards, Aaron Coburn Systems Administrator and Programmer Academic Technology Services, Amherst College (413) 542-5451 acob...@amherst.edu
[jira] [Updated] (VCL-467) Members of a group from one affiliation have access to groups with the same name from other affiliations
[
https://issues.apache.org/jira/browse/VCL-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Coburn updated VCL-467:
-
Summary: Members of a group from one affiliation have access to groups with
the same name from other affiliations (was: Members of a group from one
affiliation have access to groups from other affiliations with the same name)
> Members of a group from one affiliation have access to groups with the same
> name from other affiliations
>
>
> Key: VCL-467
> URL: https://issues.apache.org/jira/browse/VCL-467
> Project: VCL
> Issue Type: Bug
> Components: web gui (frontend)
>Affects Versions: 2.2, 2.2.1
> Environment: PHP 5.1 on CentOS 5.5
>Reporter: Aaron Coburn
> Labels: security
> Fix For: 2.3
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> A user with permission to edit a certain group for a certain affiliation has
> access to the groups with the same name from other affiliations. For
> instance, if a user is a member of admin@EXAMPLE1 and therefore can modify
> the group All users@EXAMPLE1, it turns out that the user can also modify the
> group All users@EXAMPLE2 and potentially also admin@EXAMPLE2. The reason for
> this is that the permissions check in the PHP code is based on group name
> rather than group ID. This appears to only affect the "Manage Groups" page
> and the "Privileges" page.
> I have included patches that check the value of 'editgroupid' rather than
> just 'editgroup', thereby comparing unique IDs rather than possibly
> non-unique names.
> The .ht-inc/groups.php page can be fixed with this patch:
> 137,138c137,138
> < if(array_key_exists("editgroup", $usergroups[$id]) &&
> <in_array($usergroups[$id]["editgroup"], $user["groups"]))
> ---
> > if(array_key_exists("editgroupid", $usergroups[$id]) &&
> > array_key_exists($usergroups[$id]["editgroupid"],
> > $user["groups"]))
> The .ht-inc/privileges.php page can be fixed with this patch:
> 1715c1715,1716
> <."g2.name AS editgroup "
> ---
> >."g2.name AS editgroup, "
> >."g2.editusergroupid AS editgroupid "
> 1727c1728
> < if($grpdata["ownerid"] != $user["id"] && !
> (in_array($grpdata["editgroup"], $user["groups"]))) {
> ---
> > if($grpdata["ownerid"] != $user["id"] && !
> > (array_key_exists($grpdata["editgroupid"], $user["groups"]))) {
> 2592c2593
> < foreach($_user["groups"] as $groupname) {
> ---
> > foreach($_user["groups"] as $groupid => $groupname) {
> 2594,2600c2595,2604
> < # (has cascaded $priv && ! have block at this node) return 1
> < if((array_key_exists($groupname, $privs["usergroups"]) &&
> <in_array($priv, $privs["usergroups"][$groupname]['privs']))
> ||
> <((array_key_exists($groupname, $cascadePrivs["usergroups"])
> &&
> <in_array($priv,
> $cascadePrivs["usergroups"][$groupname]['privs'])) &&
> <(! array_key_exists($groupname, $privs["usergroups"]) ||
> <! in_array("block",
> $privs["usergroups"][$groupname]['privs'] {
> ---
> > # (has cascaded $priv && ! have block at this node) return 1
> > if((array_key_exists($groupname, $privs["usergroups"]) &&
> >$groupid == $privs["usergroups"][$groupname]['id'] &&
> >in_array($priv, $privs["usergroups"][$groupname]['privs'])) ||
> >((array_key_exists($groupname, $cascadePrivs["usergroups"]) &&
> >$groupid == $cascadePrivs["usergroups"][$groupname]['id'] &&
> >in_array($priv,
> > $cascadePrivs["usergroups"][$groupname]['privs'])) &&
> >(! array_key_exists($groupname, $privs["usergroups"]) ||
> >(! in_array("block", $privs["usergroups"][$groupname]['privs'])
> > &&
> >$privs["usergroups"][$groupname]['id'] == $groupid {
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (VCL-467) Members of a group from one affiliation have access to groups from other affiliations with the same name
Members of a group from one affiliation have access to groups from other
affiliations with the same name
Key: VCL-467
URL: https://issues.apache.org/jira/browse/VCL-467
Project: VCL
Issue Type: Bug
Components: web gui (frontend)
Affects Versions: 2.2.1, 2.2
Environment: PHP 5.1 on CentOS 5.5
Reporter: Aaron Coburn
Fix For: 2.3
A user with permission to edit a certain group for a certain affiliation has
access to the groups with the same name from other affiliations. For instance,
if a user is a member of admin@EXAMPLE1 and therefore can modify the group All
users@EXAMPLE1, it turns out that the user can also modify the group All
users@EXAMPLE2 and potentially also admin@EXAMPLE2. The reason for this is that
the permissions check in the PHP code is based on group name rather than group
ID. This appears to only affect the "Manage Groups" page and the "Privileges"
page.
I have included patches that check the value of 'editgroupid' rather than just
'editgroup', thereby comparing unique IDs rather than possibly non-unique names.
The .ht-inc/groups.php page can be fixed with this patch:
137,138c137,138
< if(array_key_exists("editgroup", $usergroups[$id]) &&
< in_array($usergroups[$id]["editgroup"], $user["groups"]))
---
> if(array_key_exists("editgroupid", $usergroups[$id]) &&
> array_key_exists($usergroups[$id]["editgroupid"],
> $user["groups"]))
The .ht-inc/privileges.php page can be fixed with this patch:
1715c1715,1716
< ."g2.name AS editgroup "
---
>."g2.name AS editgroup, "
>."g2.editusergroupid AS editgroupid "
1727c1728
< if($grpdata["ownerid"] != $user["id"] && !
(in_array($grpdata["editgroup"], $user["groups"]))) {
---
> if($grpdata["ownerid"] != $user["id"] && !
> (array_key_exists($grpdata["editgroupid"], $user["groups"]))) {
2592c2593
< foreach($_user["groups"] as $groupname) {
---
> foreach($_user["groups"] as $groupid => $groupname) {
2594,2600c2595,2604
< # (has cascaded $priv && ! have block at this node) return 1
< if((array_key_exists($groupname, $privs["usergroups"]) &&
< in_array($priv, $privs["usergroups"][$groupname]['privs']))
||
< ((array_key_exists($groupname, $cascadePrivs["usergroups"])
&&
< in_array($priv,
$cascadePrivs["usergroups"][$groupname]['privs'])) &&
< (! array_key_exists($groupname, $privs["usergroups"]) ||
< ! in_array("block",
$privs["usergroups"][$groupname]['privs'] {
---
> # (has cascaded $priv && ! have block at this node) return 1
> if((array_key_exists($groupname, $privs["usergroups"]) &&
>$groupid == $privs["usergroups"][$groupname]['id'] &&
>in_array($priv, $privs["usergroups"][$groupname]['privs'])) ||
>((array_key_exists($groupname, $cascadePrivs["usergroups"]) &&
>$groupid == $cascadePrivs["usergroups"][$groupname]['id'] &&
>in_array($priv, $cascadePrivs["usergroups"][$groupname]['privs']))
> &&
>(! array_key_exists($groupname, $privs["usergroups"]) ||
>(! in_array("block", $privs["usergroups"][$groupname]['privs']) &&
>$privs["usergroups"][$groupname]['id'] == $groupid {
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (VCL-470) The vSphere module does not implement the get_total_space subroutine
The vSphere module does not implement the get_total_space subroutine
Key: VCL-470
URL: https://issues.apache.org/jira/browse/VCL-470
Project: VCL
Issue Type: Bug
Components: vcld (backend)
Affects Versions: 2.2.1
Environment: VMware ESX4 host using the perl vSphere API
Reporter: Aaron Coburn
Fix For: 2.2.1
The VMware provisioning module calls the get_total_space subroutine before
moving the VMX and VMDK files to/from the VM host machine. But when using the
VMware::vSphere_SDK module, vcld reaches a critical error because the function
is not implemented in the vSphere module. Attached is an implementation of the
needed subroutine for lib/VCL/Module/Provisioning/VMware/vSphere_SDK.pm
1797,1840d1796
< #/
<
< =head2 get_total_space
<
< Parameters : $path
< Returns : integer
< Description : Returns the total size (in bytes) of the volume specified by
the
<argument.
<
< =cut
<
< sub get_total_space {
< my $self = shift;
< if (ref($self) !~ /VCL::Module/i) {
< notify($ERRORS{'CRITICAL'}, 0, "subroutine was called as a
function, it must be called as a class method");
< return;
< }
<
< # Get the path argument
< my $path = shift;
< if (!$path) {
< notify($ERRORS{'WARNING'}, 0, "path argument was not specified");
< return;
< }
<
< # Get the datastore name
< my $datastore_name = $self->_get_datastore_name($path) || return;
<
< my $vmhost_hostname = $self->data->get_vmhost_hostname();
<
< # Get the datastore info hash
< my $datastore_info = $self->_get_datastore_info() || return;
<
< my $total_bytes = $datastore_info->{$datastore_name}{capacity};
< if (!defined($total_bytes)) {
< notify($ERRORS{'WARNING'}, 0, "datastore $datastore_name capacity key
does not exist in datastore info:\n" . format_data($datastore_info));
< return;
< }
<
< notify($ERRORS{'DEBUG'}, 0, "capacity of $datastore_name datastore on
$vmhost_hostname: " . format_number($total_bytes) . " bytes");
< return $total_bytes;
< }
<
<
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (VCL-471) Problem copying vmware files from a datastore to a management node using the vSphere API
Problem copying vmware files from a datastore to a management node using the vSphere API Key: VCL-471 URL: https://issues.apache.org/jira/browse/VCL-471 Project: VCL Issue Type: Bug Components: vcld (backend) Affects Versions: 2.2.1 Environment: VMware esx4 using the vSphere API Reporter: Aaron Coburn Priority: Minor Fix For: 2.2.1 In the copy_file_from subroutine in VCL/Module/Provisioning/VMware/vSphere_SDK.pm, the $destination_directory_path value (i.e. on the management node) is set by calling the _get_parent_directory_normal_path(). That subroutine, however, is for handling paths in the VMware datastore, and the $destination_directory_path is presumably always on the management node, so what is probably meant is simply: (on line 1402) my $destination_directory_path = basename($destination_file_path) || return; -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: windows 7 failed to start
Patrick, I have encountered some similar behavior with Cygwin. In my case, /bin/bash did not have the executable bit set on the Windows image. (`chmod +x /bin/bash` fixed that). In any case, I found the sshd error logs to be very helpful. Aaron -- Aaron Coburn Systems Administrator and Programmer Academic Technology Services, Amherst College (413) 542-5451 acob...@amherst.edu > From: Andy Kurth > Reply-To: > Date: Wed, 16 Feb 2011 13:33:23 -0500 > To: > Subject: Re: windows 7 failed to start > > Have you disabled User Account Control? Where specifically are the > errors occurring? > > -Andy > > On 2/10/2011 2:36 PM, James Patrick Sigmon wrote: >> Thanks Andy. >> >> I'm almost complete with the new Windows 7 image, but Cygwin is not >> cooperating. I keep getting permission denied errors. The folders have no >> restrictions and I am the root account with administrator access. I've tried >> a few work arounds to now avail. Have you seen this behavior before? >> >> >> >> >> >> >> -Patrick >> >> On Feb 9, 2011, at 4:09 PM, Andy Kurth wrote: >> >>> I took a closer look at the files you sent. The base image vmx is using >>> scsi0.virtualDev = "lsisas1068". The vmguest vmx is using scsi0.virtualDev >>> = "LsiLogic". Setting the vmguest vmx file to lsisas1068 should allow the >>> guest to boot. >>> >>> The VMware SDK and vim-cmd utility return "LsiLogic" even though a virtual >>> hard drive was created using the "lsisas1068" controller type. If you look >>> inside the first vmdk file, it probably also contains ddb.adapterType = >>> "LsiLogic". As a result, it's impossible for VCL to know if an image was >>> created using LsiLogic or lsisas1068. LsiLogic is used because that's what >>> VMware reported the disk to be using. >>> >>> I'd like to eventually improve the hardware compatibility by saving the data >>> from the original vmx file when an image is captured and using it to >>> generate new vmx files when reservations are made. >>> >>> For now, avoid lsisas1068. I don't know if the virtual disk can be >>> converted. I think it will be easiest to recreate the base image. Be sure >>> to expand the "Product Compatibility" option under "Guest Operating System" >>> and choose Virtual Hardware version 4. I believe this should cause it to >>> use LsiLogic. Check the virtualDev value in the vmx file before installing >>> the OS. ESXi allows you to specify which adapter to use but I don't think >>> Server 2.0 has this option. >>> >>> -Andy >>> >>> >>> >>> On 2/9/2011 12:18 PM, James Patrick Sigmon wrote: >>>> It still has the same problem with "winvista-64" in the vmx file. To >>>> clarify, the original image boots up fine, but the copy VCL makes for a >>>> reservation doesn't. >>>> >>>> Thanks, >>>> >>>> Patrick >>>> >>>> On Feb 9, 2011, at 10:53 AM, Andy Kurth wrote: >>>> >>>>> It looks like VMware Server 2.0 doesn't recognize the Windows 7 guestOS >>>>> values. Try changing it to "winvista-64" and see if this allows the VM to >>>>> boot. If this works, I can add an exception in the code to use the >>>>> winvista guestOS values for Windows 7 under VMware Server 2.0. >>>>> >>>>> -Andy >>>>> >>>>> On 2/9/2011 3:08 AM, James Patrick Sigmon wrote: >>>>>> Hey Andy, >>>>>> >>>>>> Sorry I for not responding earlier; I had to put this issue on the back >>>>>> burner for a bit for other things. >>>>>> >>>>>> Attached is the output for the vcld.log. Also, the error is currently >>>>>> captured in the attached screenshot. The vmguests for this image still >>>>>> fail to start. >>>>>> >>>>>> Here is the basic output from VMware: >>>>>> >>>>>> [root@server15 Virtual Machines]# vmware-vim-cmd vmsvc/getallvms >>>>>> Vmid Name >>>>>> FileGuest OS Version >>>>>> Annotation >>>>>> 208vmwarewin7-base-v1[local] >>>>>> vmwarewin7-base-v1/vm
