On 10/ 4/10 02:47 PM, William Schumann wrote:
On 10/ 1/10 05:28 PM, Dave Miner wrote:
This below is, to some extent, the crux of the issue in my mind:
AI client changes: 5.7.2.2 Boot process - describes what has to
happen on the AI client side. Will add description of AI client
script to fetch the profiles (getting criteria, http
request/response, handling multiple profiles). Some implementation
details are still to be decided (request URL determination, wanboot
interaction).
This definitely needs fleshing out. I was unclear as to why a second
request, with seemingly similar (if not identical) input, is required
to obtain the configuration manifest.
One of the project requirements is to decouple AI manifests from SC
profiles. I take this as meaning the fetching process as well.
Decoupling, in terms of requirements, means to ensure that the *management* of
the configuration profile(s) becomes independent of
the management of the AI manifests, thus removing the existing 1-1 relationship
that is a result of delivering the configuration
profile as a section (a comment, right now) of the AI manifest.
Delivering them simultaneously is perfectly fine, and as you can gather, I
think preferable. My point of view is that wanboot-cgi
has a quite suitable method already for delivering a bundle of content and
would like to see that leveraged, rather than inventing
yet another mechanism that is specific to system configuration.
Consider the simplicity of MIME as a way to bundle content.
Here is working code from my prototyping. It is from the SC locator Python
script, which has just read the profile entries from the
database and walks through them, including them into a single MIME-encoded
string.
from email.mime.multipart import MIMEMultipart
from email.mime.text import MIMEText
outer = MIMEMultipart()
for row in iter(query.getResponse()):
profpath = row['name']
try:
fp = open(profpath, 'r') # read static profile to a string
msg = MIMEText(fp.read(), 'plain')
msg.add_header('Content-Disposition', 'attachment',
filename = os.path.basename(profpath))
fp.close()
outer.attach(msg) # tack it onto the main document
except IOError,OSError:
On the client side, the following code takes as input the HTTP RESPONSE and
walks through the profiles attached through the
multipart type:
from email.parser import Parser
parse = Parser()
msg = parse.parsestr(response) # parse the response as a MIME document
if msg.is_multipart():
for x in msg.walk():
y = x.get_payload()
copy_to_dest(y, tmpdir) #write the profile to a destination path
else:
y = msg.get_payload()
copy_to_dest(y, tmpdir)
Were the AI manifest added to this message, it could be distinguished by specifying
"AI_manifest" in the Content-Disposition:
attachment filename.
It should also be mentioned that wanboot uses MIME to encode the entire message
-the HMAC is separated from the wanbootfs payload by
MIME multipart.
For developement and testing, OpenSolaris contrib package mpack contains
application munpack, which can be used to manually unpack a
MIME message, as can a web browser.
As a bonus, a web browser could be added as a solution for bi-directionally
securely fetching profiles through HTTPS on the AI
client. In this scenario, the user can type a passphrase to complete client
authentication.
I'm well aware that wanboot uses MIME to encode its entire message. I
am not yet convinced that we shouldn't just be using its
already-implemented capabilities to return these, however.
Dave
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
