Help Instructions should map accurately to the reality!

[codenode]

Hi,

I am a h0peless n00b, I admit it!  Still, I kinda expected the reality to match the map, 100%.  When I downloaded and installed the WD Suite v/1.95, I learned right away that I should change the SSL certificate key, since it is the same for everyone who downloads the Suite until changed by the individual user.  I was referred to a page to do that via a link.  When I got to the page in question, entitled "SSL Private/Public Key-Pair Setup for Apache 2.0", I read the following opening lines:

"For a web-server to be able to accept 'https://' requests, a private/public key-pair (for Apache2 w/ mod_ssl) needs to be generated and stored in the proper location(s).

Note: Before proceeding - the location of executable 'openssl.exe' must be in the PATH. Also, make sure that 'openssl.exe' can find its configuration file 'openssl.cnf'.

To create a self-signed private/public 1024 bit key-pair that will be valid for 365 days...

Open the commad line, and change to the directory that contains 'openssl.exe'...
cd /d C:\www\openssl\bin {NB: my emphasis}

Creates a certificate signing request (server.csr) and private key (privkey.pem).

Note:

    * 'common name' is the exact name of your website (example: www.yourdomain.com).
    * If openssl.cnf is not fully configured, you will be asked several questions.
    * While not required, openssl.cnf can be edited with the proper information; that will not be asked for if present."

The problem is that the command line opens, not surprisingly, like this:  "C:\www>", and any attempt to access "cd /d C:\www.openssl\bin", or "C:\www.openssl\bin", or just "openssl", results in an error string.  I assume that "the command line" refers to the "command prompt" of the Suite's Web-Developer Controller window?  If there is the slightest ambiguity - maybe that the "command line" refers to the MS DOS command prompt - then that should have been clarified.  Of course, I cannot know whether "the command line" and "the command prompt" are one and the same thing. 

On the GUI that comes with the program I installed (version 1.95), there seems to only be a reference to a "command prompt", not a "command line".  I am a stickler for mappings reflecting reality - believing that those who violate the sanctity of this should have their fingers broken (only one joint at a time, of course) until one absorbs the lesson.

The instructions go on to say that such and such a line should be altered, but it begins, in the above, by indicating that key pairs will be generated by writing the listed code in the command line, whatever that is!  I dare not proceed further until I am aware of what I am doing.  I need specifically to know where the devil the "command line" referred to is located, and if it is the same as the command prompt in the Suite, then how the devil one can generate the key pairs mentioned, since the given code string  only generates errors.  I might add that I did eventually get into the "openssl" directory by simply writing "dir" at the C:\www> prompt.  I could see that there was indeed an "openssl" directory, and I could also enter that directory, but since I was unable to first generate the key pairs mentioned, there was no point in proceeding further.

I will end my rant here, in case it turns out that "command line" and "command prompt" are NOT the same animals...


Yours,
codenode

[admin]

The command-line and the command-prompt, in this case, are one and the same. People tend to use those terms interchangeably and even I have no idea now which is the more correct one. I suppose it depends on the scope.

It's the cmd.exe shell, DOS shell, etc, in this case.

The WDC menu for the "command prompt" opens up cmd.exe with the current location set to C:\www. You could also just Run 'cmd.exe' and type in...
cd C:\www
...to get the same effect.

The problem is that the command line opens, not surprisingly, like this:  "C:\www>", and any attempt to access "cd /d C:\www.openssl\bin", or "C:\www.openssl\bin", or just "openssl", results in an error string.

"C:\www.openssl\bin"? Maybe that was just a typo here, but that should be "C:\www\openssl\bin"

Opening up that command prompt and typing in...
cd /d C:\www\openssl\bin
...works for me.

Just make sure you have the drive letter correct. What error string are you getting?

[codenode]

First, thanks for pointing out the "dot"!  My fatal error!!!  At first when I read your reply I believed that the dot above was either a typo or was a verbatim transcript of the code indicated on the mentioned DevSide link.  That turned out not to be the case in either circumstance - I apparently did write "www." rather than "www\", perhaps out of normal (Windows) "web" habit, and the code string given on the aforementioned link was "dotless".  In any case, when I substitute the backslash for the dot, I do indeed get on the path, "C:\www\openssl\bin". 

I must now see if I can generate the key pairs as instructed.  If I run into a snag there I will see if I can find an answer to that problem here on the forums, otherwise I will present it here. 

Regarding the distinction between "command line" and "command prompt", it is possible that people in everyday practice use the terms interchangeably, but semantically (syntactically?) speaking, one should probably say that the command line is the DOS line where the Command Prompt blinks (and note that the reason why I do not capitalize the words "command line" is because it is not a title anywhere (unlike like "Other", "Help", or "Command Prompt"), nor is it a tool, like the Command Prompt.  I guess what I expeced from the instructions - my complaint about poor mapping - was 100% unambiguous instructions to "click on the Other submenu of the main menu toolbar of the Web-Developer Controller window, then click on Command Prompt to access the command line". : - }  Viciously adhered to unambiguity is a must, in my experience, when giving instructions to n00bs!


Thanks again for your helpful reply,

codenode

[codenode]

Hey, by the way, I have another question that in a way is even more basic:  can I use the Suite (the freebee version 1.95) to create a sort of virtual www environment on my PC (that seems to be precisely what the Suite does, i.e., creates a www "localhost" directory) in which I can develop my website in a dry-run environment, then upload the whole shebang once all the bugs have been zapped, or does the Suite presume that one is using one's own server - for example, a Linux box - to host one's own site? 

At first I was thinking that the Suite could only be used in the latter (own-hosting) instance, but I am now beginning to come around to the happy notion that I can in fact use the Suite to develop my website in a safe, dry-run environment, then, once everything is functioning satisfactorily, I can upload my site (actually it is already there, but only in "This site under construction" form, but "uploading" the new version will entail overwriting the current files).  So, what's the skinny, can I or can I not, a non-own-host'er, use the Suite to develop my website in the "localhost" environment?

Thanks!

codenode

[admin]

but I am now beginning to come around to the happy notion that I can in fact use the Suite to develop my website in a safe, dry-run environment, then, once everything is functioning satisfactorily, I can upload my site...

That is what I do with all my websites.

You can use it for both self-hosting and/or local development and testing...

As long as you do not use anything Windows specific under PHP, and have the ability to update the PATHs under the code, you should be able to upload your webroot and your MySQL database to your Linux host. At the end of the day PHP is PHP, and so on.

The only problem is when you have major versions of PHP and/or MYSQL mismatched...

We are using PHP v5, and a lot of hosts use v4.4. 95% of the time this is not a problem, but there are PHP functions and extensions that are only present under v5. Nothing general, just specific stuff.