svnadmin dump /path/to/repository > repository-name.dmp

Copy the dump file to the new server.  There, create a new repository to house the dumped information:

cd /path/to/new/repository

svnadmin create repository-name

svnadmin load repository-name < repository-name.dmp

Now, if you have a project that you checked out from the old location, that you want to point to the new location, run the following command (assumes you’re located in the root of the directory housing the checkout you want to switch:

svn switch –relocate svn+ssh://old/path  svn+ssh://new/path .

There are several ways to accomplish this - but this is how I like to do it (this is from a linux command shell):

find . -name somefile -exec perl -pi.bliki -e ’s/textToFind/replacement/g’ {} \;

The above command uses the find command, starting from the current location (.), looking for files named ’somefile’ (-name somefile), and every time it finds one, it runs the command following the -exec parameter.  The command following the -exec parameter is a perl one-liner that backs up the file it’s about to modify (with a .bliki extension, I just try to pick something I’m sure will not result in overwriting a legitimate file), and then does a global search and replace of textToFind with replacement.  In the above command, the {} is where find inserts the current file it has found.  You must backslash the semi-colon at the end so that the shell doesn’t interpret it and leaves it for use by the find -exec command.

Once you’ve completed the search and replace, you use the following command to go through and remove all of the backup files created with the .bliki extension.

find . -name somefile.bliki -exec rm {} \;

Hope this makes sense?

Post questions if you need clarification on anything.

var f:File = File.applicationStorageDirectory.resolvePath(”Test.txt”);
trace(f.nativePath + ‘ is where my file is stored’);

You’ll need the openssl tool on your Linux node to do this.

• Put the contents of the public SSL cert and the private key into one file. Easiest way to do this would be to cat the public cert and append to a new file. Then cat the private key and append to that same file. For the purposes of the next steps, we’ll call this new file ‘newcert.crt’.
• Now, run: openssl pkcs12 -export -in newcert.crt -out iiscert.p12 -name “My Certificate”
  • Where ‘newcert.crt’ is the file that we created in the first step, and ‘iiscert.p12′ is the file that will be imported into IIS
• Securely (i.e. scp or something that won’t send the file in clear text - it contains your private key!) copy the iiscert.p12 file to the IIS server you’ll be using it on.
• Use the certificates MMC to import the iiscert.p12 file into the Personal certificate store for the computer object.
• Now use IIS to configure the default web page and replace the current certificate with the new one that was just imported.

Voila! Now you have a cross-platform SSL cert you can use.

Since my impulse purchase of a year ago - I have learned that there is a web site you can go to which will scan your computer hardware and tell you whether it’ll be able to play that new video game you’re contemplating.  It is found here: http://www.systemrequirementslab.com/referrer/srtest.  Happy hunting.

 here's a CMD shell tip that works in W2K, WXP, and W2K3.

There is a BASIC MIDSTR function equivalent in batch files... use this syntax as a modifer:

~:start,end

e.g.

set foo=\\servername
@echo unretouched [%foo%]
@echo modified [%foo:~2,99%]

will output:

unretouched [\\servername]
modified [servername]
 

In a corporate network, this is a handy thing to have, for example, if you want to ping the server indicated in the LOGONSERVER variable, which is a UNC instead of just a host name:

ping %logonserver:~2,99%

Or let's say that you want the day of the week. This:

@echo unretouched [%date%]
@echo modified [%date:~0,3%]

will output:

unretouched [Tue 05/06/2008]
modified [Tue]

Nifty.
 

See the help at the end of “FOR /?” for other expansions to variables in file paths, some or all of which are repeated below.

See the Windows Help (no, seriously) and search for “using batch parameters” for lots of interesting expansions, e.g.

%~1 Expands %1 and removes any surrounding quotation marks (”").
%~f1 Expands %1 to a fully qualified path name.
%~d1 Expands %1 to a drive letter.
%~p1 Expands %1 to a path.
%~n1 Expands %1 to a file name.
%~x1 Expands %1 to a file extension.
%~s1 Expanded path contains short names only.
%~a1 Expands %1 to file attributes.
%~t1 Expands %1 to date and time of file.
%~z1 Expands %1 to size of file.
%~$PATH:1 Searches the directories listed in the PATH environment variable and expands %1 to the fully qualified name of the first one found. If the environment variable name is not defined or the file is not found, this modifier expands to the empty string.
Andrew.

To understand how the whole SSL encryption process works, check out this article here.

From the server you’re going to install the ssl certificate onto, do the following:

• Create the SSL Certificate request
  • openssl req -new -nodes -keyout newkey.pem -out newreq.pem
    • this generates a new ssl certificate request, newreq.pem, and a new private key (unencrypted),newkey.pem. Default bits to create new private key is 1024
    • You’ll be prompted for several different bits of information, the most important one is the ‘common name’. You’ll want to make sure that it is the same as what you want clients to use when connecting to you over the Internet (i.e. www.myhost.com).
    • Don’t forget this part! make your private key file readable only by root, to keep it secure
• You now need to take the cert request file (newreq.pem) and give it to a Certificate Authority (CA) and obtain a signed certificate from the CA in return. Depending on whether you administer the CA or your ISP does it, the end result should be that you’re left with a resulting certificate that is in PEM format. I won’t go into the details of how to do the CA side of things here - I’ll assume that you’re probably just going to copy and paste the newreq.pem file into a page on your ISP’s web site, upon which they’ll make a signed certificate available to you, i.e. newcert.pem.
• Once you have the signed certificate, you need to place it in the appropriate location and make configuration changes to the software that is going to use it.
  • For example, if you were using the certificate for Apache for a web site you’re wanting clients to access over HTTPS:
    • in your httpd.conf file for the site you’re administering, you’d add [SSLCertificateFile /path/to/newcert.pem] (without brackets, they’re included from here on out for readability’s sake).
    • You have the option of including the private key within the newcert.pem file, by simply cat-ing it and appending to the file. But you can also keep them separate (my preference) and just add the following additional config line to httpd.conf [SSLCertificateKeyFile /path/to/newkey.pem].
    • You need to have a ‘lookup’ for the client connecting to your site, so their browser will know where to go to verify your certificate. The file used by default gets generated when you compile/install Apache. Just find it and copy it into the directory which holds your other keys and point to it with the following directive.
      [SSLCACertificateFile /path/to/ca-bundle.crt]. If you CA is not a publicly registered CA, it’s not going to be included in this file, and you’ll need to obtain the certificate for the CA and append it to this file. Generally this would be accomplished by your CA Admin providing you with a plain text file that you simply cat and append to this ca-bundle.txt file.
    • If your SSL signing authority delegates its signing authority to ’subordinate CA’s, then you also may need a ‘Certificate Chain’ file, so that the connecting clients will know how to follow a CA’s authority up the ‘chain’ to the parent CA and verify your certificate that way. If you require a certificate chain file, your ISP will indicate it as part of their instructions for getting your certificate installed. To include it, you use the following directive [SSLCertificateChainFile /path/to/intermediate-bundle.crt].
    • There are a lot of other config options that are necessary for SSL, but there are plenty of examples for that out there. My purpose here is just to help you understand/implement the certificate piece of things. Now restart Apache and verify that you can connect to your web server over port 443 via HTTPS.
  • If instead, you were planning on using the certificate for, say, TLS connectivity with postfix:
    • copy all of your certs (private key, public certificate, CA certificate) into the /etc/postfix directory, or wherever else you want them to live.
    • modify your main.cf to contain [smtpd_tls_security_level = may] in order to enable ability to receive TLS encrypted traffic.
    • in main.cf, add [smtpd_tls_key_file = /etc/postfix/newkey.pem] to tell postfix what to use as the private key
    • in main.cf, add [smtpd_tls_cert_file = /etc/postfix/newcert.pem] to tell postfix what to use as the public cert
    • in main.cf, add [smtpd_tls_CAfile = /etc/postfix/cacert.pem] to tell postfix what to use as it’s list of trusted root CAs. If your cert was signed by a CA that is not included in this file, then you’ll need to append your CA’s cert to the end of this file.
    • in main.cf, add [smtp_tls_security_level = may] in order to tell postfix to utilize TLS if offered by the receiving server upon connecting (host will advertise STARTTLS).
    • set the settings for the smtp process to the same as those for smtpd, via the following: [smtp_tls_key_file = $smtpd_tls_key_file], [smtp_tls_cert_file = $smtpd_tls_cert_file], [smtp_tls_CAfile = $smtpd_tls_CAfile]
    • save main.cf and reload postfix.
• If you wanted to check and make sure that you could connect to postfix over a TLS connection, the best way to test is like this:
  • openssl s_client -connect hostname:25 -starttls smtp
• If you want to check SSL connectivity to your HTTPS secured web site, do it like this:
  • openssl s_client -connect hostname:443