krypted.com

Tiny Deathstars of Foulness

To tell curl that you can read and write cookies, first we’ll start the engine using an empty cookie jar, using the -b option, which always reads cookies into memory:

curl -b newcookiejar http://krypted.com

If your site can set cookies you can then read them with the -L option

curl -L -b newcookiejar http://krypted.com

The response should be similar to the following:

Reading cookies from file

Curl also supports reading cookies in from the Netscape cookie format, used by defining a cookies.txt file instead:

curl -L -b cookies.txt http://krypted.com

If the server updates the cookies in a response, curl would update that cookie in memory but unless you write something that looks for a new cookie, the next use will read the original cookie again.

To create that file, use the -c option (short for –cookie-jar) as follows:

curl -c cookie-jar.txt http://krypted.com

This will save save all types of cookies (including session cookies). To differentiate, curl supports junk, or session cookies using the –junk-session-cookies options, or -j for short. The following can read these expiring cookies:

curl -j -b cookie-jar.txt http://krypted.com

Use that to start a session and then that same -c to call them on your next use. This could be as simple as the following:

CURL=/usr/bin/curl
COOKIEJAR=cookie-jar.txt
SITE=http://krypted.com
$CURL -j -b $COOKIEJAR $site

You can also add a username and password to the initial request and then store the cookie. This type of authentication and session management is used frequently, for example in the Munkireport API, as you can see here:

For converting, the -b detects if a file is a Netscape formatted cookie file, parses, then rewrites using the -c option at the end of a line:

curl -b cookie.txt -c cookie-jar.txt http://krypted.com

February 20th, 2017

Posted In: Mac OS X, Mac Security

Tags: , , , , , ,

If you have a web host that supports cPanel (a number do) then moving to Google Apps for Mail couldn’t be simpler. Just log in to your cPanel account and click on the Mail icon in the top left corner. From here, click on the last item in the list, Modify Mail Exchanger (MX Entry). Then click on change an MX Entry. In the Change MX for… drop down list, select the appropriate domain (if you only have one then there should be only the one to change and then enter aspmx.l.google.com in the to: field, clicking Change when you are done. According to the TTL value you will then need to wait for DNS replication to occur (it can take up 72 hours in some cases). In the meantime, mail should start to flow into your Google Apps mailboxes.

The next step is to actually migrate your mail. Assuming your administrator supports IMAP for your mailboxes this should be a fairly straight forward process. From the Google Apps administrative dashboard click on Advanced Tools in the blue toolbar. Then click on Migrate mail from mail server on the Advanced page and you will see a screen asking you to enter some information about your source IMAP server (the one that currently has all your data). In the Host field, type your domain name. cPanel uses Exim, which can work with the Dovecot setting in the Server software: field. Then enter 143 into the port number field (unless you use a different port) and if you use an IMAP prefix enter it now. You will also need to enter a maximum number of connections (according to how much data you want it to attempt to migrate at once).

Now you select the users whose data you will be moving. Click Next, and then choose whether to upload one or many accounts. Assuming one, you would simply enter the originating user name, target user name (in most cases these are the same) and then the password of the mailbox in cPanel. This means you need to know all your passwords, or reset them at the time of migration. Assuming many users, you would do the same thing in a csv file, creating a spreadsheet with username, source username, and source password as the columns and then populating the information from cPanel. Once done, save as csv and then use this screen to upload the file. Whichever option you chose, click on Start Migration to migrate the mail and then wait for the migration to complete.

If mail will not migrate using the stock example, searching Google for answers is a start but many may need to script solutions using the Google Apps email migration API.

POP mail will stay in the mailbox it was downloaded into. However, once you are done, POP users might end up redownloading mail. Contacts and calendars should be stored on your local devices and if you wish to migrate those you can (although this is going to be a more complicated process).

You will also need to change the local settings if you haven’t built a CNAME in DNS to point your old incoming and outgoing server addresses to the incoming addresses that Google uses. Client configuration should be a username of the full email address, the password you entered into your Google Apps domain dashboard and the incoming server name of imap.gmail.com. The outgoing mail server (SMTP) will be smtp.gmail.com and it will require authentication with the same information used for incoming (POP or IMAP) mail.

July 10th, 2009

Posted In: Mac OS X

Tags: , , , , , , , , , , , , , ,