Enquanto isso, na reparti��o... » Nerdocracia

Private GIT repositories (on DreamHost)

MaCa — Tue, 09 Nov 2010 00:58:32 +0000

This is yet another guide describing how to setup private HTTP-accessible Git repositories on Dreamhost using Git’s git-http-backend (a.k.a git’s Smart HTTP protocol). While similar guides can easily be found by the thousands in the Web (I’ve listed some of them in the Refereces section), I’ve found that some guides have outdated information or that the setup described in them could be improved. Thus, this guide tries to update, improve and consolidate the information dispersed in such sources.

Notice:

the original guide is available at http://github.com/tmacam/private-git-on-dreamhost. Nevertheless, its content as on 2010-11-08, is presented bellow.

Private GIT repositories (on DreamHost)

Author:	Tiago Alves Macambira
Licence:	Creative Commons By-SA

Table of Contents

1 Introduction
- 1.1 Assumptions and requirements
- 1.2 About this document
2 Installation
3 Usage
4 Final remarks
5 TODOs
6 References

1 Introduction

This is yet another guide describing how to setup private HTTP-accessible Git repositories on Dreamhost using Git's git-http-backend (a.k.a git's Smart HTTP protocol). While similar guides can easily be found by the thousands in the Web (I've listed some of them in the Refereces section), I've found that some guides have outdated information or that the setup described in them could be improved. Thus, this guide tries to update, improve and consolidate the information dispersed in such sources.

Some might ask "Why on Earth would someone opt to create its own private Git hosting solution while better offerings are available from sites such as, let's say, GitHub?" As the guy from RailsTips pointed out in one of his articles, sometimes you don't need or don't want to "share" a project with anyone but yourself and paying for a GitHub-like service might just not make sense. If that's your case, than this guide is for you.

While aimed at a Dreamhost-hosted accounts and the environment such accounts have as of 2010-10-17, I believe the process described here can be used in other hosting providers as well.

It is important to highlight that one of the objectives of this guide is to describe a process that:

should be easy to perform by just renaming or editing this guide's companion files and
once complete, can be easily be reused to generate other "collection of repositories", with different URLs and passwords.

1.1 Assumptions and requirements

No WebDav or SSH support is needed nor used for serving Git repositories.

Once again, the focus is on HTTP access using git-http-backend. As for SSH, guides describing how to setup a similar environment for SSH-accessible repositories can be found easily on the web.
Repositories will be password protected and available for both reading and writting.

As we will explain latter, in the Setup git-http-backend for your repositories section, we will have to password-protect our repositories in order to be able to git push to them through HTTP.
We will stick to a DRY (Don't Repeat Yourself) philosophy.

Thus, we want configuration options to be repeated in as few places as possible. We will use environment variables in Apache configuration files to do this. If this makes you uncomfortable, well, you can always manually spread configuration options all over the place. Your call.
The web server being used is Apache.

Well, that is what Dreamhost allows me to use so that is going to be the focus of this guide. While it should not be that difficult to port the settings here to something suitable for another web server, describing how to do it is out of the scope of this guide.
We are able to run CGI scripts.

DreamHosts puts some restrictions on how a CGI script can be executed and the environment where it runs. We will abide to those restrictions.

ScriptAlias is not allowed by the web server.

The instructions given in git-http-backend manpage will not work as they use ScriptAlias. The idea is to use common CGI scripts and mod_rewrite instead, roughly following the ideas presented in http://wiki.dreamhost.com/Git#Smart_HTTP .
SuExec is used to run CGI scripts.

Notice that, as stated in DreamHost page on CGI, SuExec "wipes out all environment variables that don't start with HTTP_". All our env. vars. will have this prefix.
Your private git repositories will be accessible in a subpath of your domain.

The idea is that your private git repos will be available in an address such as http://www.example.tld/corporate-git/. Adapting the instructions bellow so you can serve them from the root of a domain of its own, say http://corporate-git.example.tld should be fairly simple.

1.2 About this document

This document and its companion files are initially hosted on http://github.com/tmacam/private-git-on-dreamhost.

The file README.rst is generated from README-real.rst. So, if you plan on doing any updates or fixes, README-real.rst is the file you ought to edit. Just run make afterwards in order to get README.rst updated as well. This is done because I wanted to use GitHub's automatic rendering of README files but I didn't want to just paste the contents of the companion files in this README.rst and risk getting the Guide and files out of sync. Unfortunately, GitHub does not allow the use of RestructuredText's include directive, so I had to fake it -- and here is the reason why we have README-real.rst.

This guide is distributed under the Creative Common BY-SA license while companion files are distributed under a MIT License.

2 Installation

All the commands and instructions given bellow should be performed on the machine in Dreamhost where your account is installed. So ssh to it and let's start.

2.1 Install Git

Well, this should probably be a non-issue since git comes pre-installed on most Dreamhost machines. To verify it:

$ git --version
git version 1.7.1.1

As you see, the box that serves my domain in dreamhost has git version 1.7.1.1 installed. Anything greater than 1.6.6 shall do.

If you don't have git installed in you box, have an old version or if for some other reason your need to compile git, follow Craig's instructions in Hosting Git Repositories on Dreamhost.

2.2 Create the directory where your repositories will live

It should reside somewhere not accessible from the web or directly served by the web server. We will tell Apache and git-http-backend how to properly and securely serve those repositories latter. For now, we want them protected from third parties.

Say we decided to store them in ~/private_repos/. We will refer to this directly by GIT_REPOS_ROOT in the rest of this guide. Create this directory and protect it against filesystem access from others:

export GIT_REPOS_ROOT="~/private_repos/"
mkdir ${GIT_REPOS_ROOT}
chmod 711 ${GIT_REPOS_ROOT}

2.3 Setup the bare repository creation script

We will use the script newgit.sh, presented bellow, to create new repositories [1] [2] . Remember to modify the value of the GIT_REPOS_ROOT variable in it to match our setup:

#!/bin/bash
 
# this script is based on code from the following blog post
# http://arvinderkang.com/2010/08/25/hosting-git-repositories-on-dreamhost/
# and http://gist.github.com/73622
 
 
set -e
 
 
# Please, configure a default GIT_REPOS_ROOT to match your config
#GIT_REPOS_ROOT="~/private_repos/"
 
DEFAULT_DESCRIPTION='no description :('
 
 
# describe how the script works
usage()
{
  echo "Usage: $0 [ -h ] [ -r directory] [ -d description ] [ -n projectname ]"
  echo ""
  echo "If no projectname is given, the name of the parent folder will be used as project name."
  echo ""
  echo "  -r directory   : (root) directory holding your git repositories"
  echo "  -d description : description for gitweb"
  echo "  -h             : print this screen"
  echo "  -n name        : name of the project (should end in .git)"
  echo ""
}
 
DESCRIPTION=${DEFAULT_DESCRIPTION}
 
# evaluate the options passed on the command line
while getopts r:d:n:h option
do
  case "${option}"
  in
    r) GIT_REPOS_ROOT=${OPTARG};;
    d) DESCRIPTION=${OPTARG};;
    n) REPONAME=${OPTARG};;
    h) usage
      exit 1;;
  esac
done
 
# check if repositories directory is given and is accessible
if [ -z $GIT_REPOS_ROOT  ]; then
    usage
    exit 1
fi
if ! [ -d $GIT_REPOS_ROOT  ]; then
    echo "ERROR: '${GIT_REPOS_ROOT}' is not a directory"
    echo ""
    usage
    exit 1
fi
 
 
# check if name of repository is given. if not, use folder name
if [ -z $REPONAME ]; then
  REPONAME=$(basename $PWD)
fi
 
# Add .git at and if needed
if ! ( echo $REPONAME | grep -q '\.git$'); then
  REPONAME="${REPONAME}.git"
fi
 
 
#
# Ready to go
#
 
 
REP_DIR="${GIT_REPOS_ROOT}/${REPONAME}"
mkdir ${REP_DIR}
pushd ${REP_DIR}
git --bare init
git --bare update-server-info
cp hooks/post-update.sample hooks/post-update
chmod a+x hooks/post-update
echo $DESCRIPTION > description
# This mark the repository as exportable.
# For more info refer to git-http-backend manpage
touch git-daemon-export-ok
popd
exit 0

Move or copy this file to an appropriate path (say, your home directory would be fine) and turn it into an executable:

chmod u+x ~/newgit.sh

[1]	This script is based in http://gist.github.com/73622

[2]	Other guides prefer to use something similar wrapped as a Bash function but I'd rather have it as a script

2.4 Apache Setup

Now, let's configure Apache to securely serve those repositories.

2.4.1 Setup your .htaccess

As we stated in Assumptions and requirements, we want to serve our files from http://www.example.tld/corporate-git/. So, go to the directory holding your domain files (~/www.example.tld, in our exemple), create a corporate-git directory in it if it doesn't exist yet and create a .htaccess file in it:

cd ~/www.example.tld
mkdir corporate-git
cd corporate-git
export GIT_WEB_DIR=`pwd` # we will use it in latter steps
touch .htaccess
chmod 644 .htaccess

Now, edit this .htaccess contents to match the text presented bellow or just copy the contents of the file model-htaccess into it and adapt it to match your config:

Options +Indexes
 
# GIT BEGIN ###########################################################
 
SetEnv HTTP_GIT_PROJECT_ROOT /home/user/private_repos/
SetEnv HTTP_GITWEB_CONFIG /home/user/private_repos/gitweb_config.perl
 
 
RewriteEngine On
DirectoryIndex  gitweb_wrapper.cgi
# The following two rules can be used instead of DirectoryIndex
#RewriteRule ^$  gitweb_wrapper.cgi/ [L,E=SCRIPT_URL:/$1]
#RewriteRule ^([?].*)$ gitweb_wrapper.cgi/ [L,E=SCRIPT_URL:/$1]
 
# Everything else that is not a file is forwarded to git-http-backend
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^([^?].+)$ git-http-backend-private.cgi/$1
 
 
# GIT END ############################################################
 
# AUTHENTICATION BEGIN ###############################################
AuthType Digest
AuthName "Private Git Repository Access"
# UNCOMMENT THE LINE BELLOW FOR BETTER PERFORMANCE
# AuthDigestDomain /corporate-git/
AuthUserFile /home/user/private_repos/.htpasswd
Require valid-user
# AUTHENTICATION END  ################################################

For now we will focus on the area between the # GIT BEGIN and # GIT END blocks. Modify HTTP_GIT_PROJECT_ROOT to match you setup: it should point to the full path where you store your private repositories. Just expand the value of GIT_REPOS_ROOT to get this information:

$ (cd ${GIT_REPOS_ROOT}; pwd)
/home/user/private_repos/

So, in our example, HTTP_GIT_PROJECT_ROOT value should be set to /home/user/private_repos/, as presented in the example above.

2.4.2 Setup git-http-backend for your repositories

Not we will create a CGI script that will invoke git-http-backend. In your .htaccess this script is referred as git-http-backend-private.cgi. Create it in the same directory where you .htaccess is by coping the one that comes with this guide to that directory or by creating an empty file with the following contents:

#!/bin/sh
export GIT_HTTP_EXPORT_ALL=1
export GIT_PROJECT_ROOT=${HTTP_GIT_PROJECT_ROOT:?HTTP_GIT_PROJECT_ROOT env. variable not set. Aborting.}
/usr/lib/git-core/git-http-backend

Turn it into an executable file:

chmod 755 git-http-backend-private.cgi

Attention!

You may need to update the path to git-http-backend executable if git was installed in a non-default location.

And that's it. No need to setup anything: all the settings this scripts are passed to it through environment variables set by Apache and defined in the .htaccess file.

From this point on you should be able to create repositories from the command line and access them through HTTP, but they will be read-only. As stated in git-http-backend manpage, "by default, only the ``upload-pack`` service is enabled, which serves git ``fetch-pack`` and git ls-remote clients, which are invoked from ``git fetch``, ``git pull``, and ``git clone``". For write access, i.e., to be able to perform a git push, the receive-pack service is needed, and it is only enabled when the client is authenticated.

2.4.3 Password-protect your repository

We are almost set. Let's configure password protection for this whole thing. We will focus on the latter part of your .htaccess, the one between # AUTHENTICATION BEGIN and # AUTHENTICATION END that we reproduce bellow:

# AUTHENTICATION BEGIN ########################
AuthType Digest
AuthName "Private Git Repository Access"
AuthUserFile /home/user/private_repos/.htpasswd
Require valid-user
# AUTHENTICATION END  #########################

You will have to create the password file pointed by AuthUserFile and use the htdigest tool to add a user to this file

touch /home/user/private_repos/.htpasswd
htdigest /home/user/private_repos/.htpasswd "Private Git Repository Access" username

You will be prompted for a password. And that's it.

Notice:

we are using Digest Authentication. It is supposed to be more secure than plain authentication.
The password file should be keep in a place not directly accessible from the web. Ideally it should not even be placed in the directory to be served by git-http-backend but I'm lazy and I hope this will be enough.
If you update the value of the AuthName setting you must also change the 2nd. parameter passed to htdigest, i.e., the Realm, as they must match! Odd, I know. But that's the way it is.

2.4.4 Setup GitWeb

If you followed this guide up to this point than you are able to use your repositories with git with no major issues. But you will not be able to browse them with a web browser, retrieve the list of repositories you have, see diffs, commit messages nor nothing like that. To make things better, let's install GitWeb, another CGI interface that will provide a web interface that allows to do all those things I just said you couldn't.

Note

Most of the content in this section comes from Kang's Hosting Git repositories on Dreamhost.

2.4.4.1 Retrieving and installing

GitWeb comes in the same source package as git itself. Unfortunately, Dreamhost doesn't install it by default so we will have to install it manually ourselves. Do your remember what is your git version? No? Find it all:

git --version

Go to git homepage and download the corresponding source package. In my example, in which my git version is 1.7.1.1, I would need to grab the git-1.7.1.1.tar.gz source package:

cd ~ # Yep, we will download it in our home directory
wget http://www.kernel.org/pub/software/scm/git/git-1.7.1.1.tar.gz

Unpack it, build GitWeb:

tar zxvf git-1.7.1.1.tar.gz
cd git-1.7.1.1
make prefix=/usr/bin gitweb/gitweb.cgi
rm gitweb/gitweb.perl # we won't need it

We will install it into ~/gitweb/:

export GITWEB_INSTALL_DIR="~/gitweb"
cp -r gitweb ${GITWEB_INSTALL_DIR}

We are almost there.

2.4.4.2 Setting up GitWeb

Now, copy all the GitWeb's media files into the directory where your .htaccess is:

cp ${GITWEB_INSTALL_DIR}/*.{css,png,js} ${GIT_WEB_DIR}
# in this example, GIT_WEB_DIR points
# to ~/www.example.tld/corporate-git

Get back to where your .htaccess file is (i.e. GIT_WEB_DIR). We will create a wrapper CGI for GitWeb. Just copy gitweb_wrapper.cgi or create an empty file with the contents bellow:

#!/bin/bash
export GITWEB_CONFIG=${HTTP_GITWEB_CONFIG:?HTTP_GITWEB_CONFIG env. variable not set. Aborting.}
export GIT_PROJECT_ROOT=${HTTP_GIT_PROJECT_ROOT:?HTTP_GIT_PROJECT_ROOT env. variable not set. Aborting.}
 
${HOME}/gitweb/gitweb.cgi

Turn it into an executable file:

chmod 755 gitweb_wrapper.cgi

Attention!

If you have installed gitweb files in a different directory, you will have to update this file to match the install location.

Once again, we are using settings stored in .htaccess file and passing them to a script using environment variables set by Apache. In this case, we are informing the wrapper script where our repositories are with HTTP_GIT_PROJECT_ROOT, and informing it where GitWeb configuration file is with HTTP_GITWEB_CONFIG. The wrapper script, in turn, will forward these informations to both GitWeb and to its config file.

Now, let's create GitWeb configuration file. Just copy gitweb_config.perl provided with this guide to ${GIT_REPOS_ROOT}/gitweb_config.perl or create an empty file in that path location with the following contents:

# where is the git binary?
$GIT = "/usr/bin/git";
# where are our git project repositories?
$projectroot = $ENV{'GIT_PROJECT_ROOT'};
# what do we call our projects in the gitweb UI?
$home_link_str = "My Git Projects";
#  where are the files we need for gitweb to display?
@stylesheets = ("gitweb.css");
$logo = "git-logo.png";
$favicon = "/favicon.png";
# what do we call this site?
$site_name = "My Personal Git Repositories";

You can customize it a little bit, if you want, but the most important setting, $projectroot, is set to match the value of HTTP_GIT_PROJECT_ROOT, a env. var. set by Apache.

Notice that this file, gitweb_config.perl is stored in the same directory where your repositories are, in ${GIT_REPOS_ROOT}. If, for some reason, you prefer to store it elsewhere, you will have to update this information in the .htaccess file.

2.5 Troubleshooting

So, something is not working as expected?

2.5.1 Disable authentication

Comment out the authentication code. This will ease your "debugging" process.

Remember to uncomment it latter.

2.5.2 Use info.cgi script to check CGI script's environment

A nice way to check if there is something really wrong with your setup is to use the info.cgi, whose code is presented bellow. This script is only a minor modification to the one presented in Dreamhost wiki page on CGI and allows your to do verify if you are able to execute CGI scrips and what settings Apache is passing to the other CGI scripts we use here.

#!/bin/sh
 
# disable filename globbing
set -f
 
echo "Content-type: text/plain; charset=iso-8859-1"
echo
 
echo CGI/1.0 test script report:
echo
 
echo argc is $#. argv is "$*".
echo
 
echo SERVER_SOFTWARE = $SERVER_SOFTWARE
echo SERVER_NAME = $SERVER_NAME
echo GATEWAY_INTERFACE = $GATEWAY_INTERFACE
echo SERVER_PROTOCOL = $SERVER_PROTOCOL
echo SERVER_PORT = $SERVER_PORT
echo REQUEST_METHOD = $REQUEST_METHOD
echo HTTP_ACCEPT = "$HTTP_ACCEPT"
echo PATH_INFO = "$PATH_INFO"
echo PATH_TRANSLATED = "$PATH_TRANSLATED"
echo SCRIPT_NAME = "$SCRIPT_NAME"
echo QUERY_STRING = "$QUERY_STRING"
echo REMOTE_HOST = $REMOTE_HOST
echo REMOTE_ADDR = $REMOTE_ADDR
echo REMOTE_USER = $REMOTE_USER
echo AUTH_TYPE = $AUTH_TYPE
echo CONTENT_TYPE = $CONTENT_TYPE
echo CONTENT_LENGTH = $CONTENT_LENGTH
echo ""
echo HTTP_GIT_PROJECT_ROOT = $HTTP_GIT_PROJECT_ROOT
echo HTTP_GITWEB_CONFIG = $HTTP_GITWEB_CONFIG
 
exit 0

Copy it to GIT_WEB_DIR, turn it into an executable script (chmod 755 ...) and point your browser to it ( That would be http://www.example.tld/corporate-git/ in our example).

2.5.3 Check the server logs

We are listing this as a last step but that's probably the fist place where you should have looked for clues: your server logs.

For example:

[Mon Oct 25 18:30:28 2010] [error] [client 150.164.3.192] Service not enabled: 'receive-pack'

This message says that 'receive-pack' was not enable -- probably because you are trying to push to a repository and authentication was disabled. As we explained in Setup git-http-backend for your repositories, you must use authentication to be able to write (push) to repositories using git-http-backend.

This one should be pretty obvious:

Digest: user username: password mismatch: /corporate-git/test.git/info/refs

And so on...

3 Usage

So everything is ready to use. How do you actually create and use these new repositories?

3.1 Creating new bare repositories

In order to create a new repository, say toyproject.git, all you have to do is ssh into your Dreamhost account and:

~/newgit.sh -r ${GIT_REPOS_ROOT} -d "My first private repository" -n toyproject

That's it: your created and empty repository in you repository collection. You can clone it if you want.

3.2 Cloning an empty repository

So, you got a new pristine and empty repository. Let's clone it, shall we?:

$ git clone http://username@www.example.tld/corporate-git/toyproject.git
Initialized empty Git repository in /private/tmp/teste/.git/
Password:
warning: You appear to have cloned an empty repository.

Important

Have you noticed that we have a username@ in the URL? This tells git that it must athenticate to the server before trying to access the git repository.

In this example, we are acessing the repository with the crentials of the user username, the one we setup in Password-protect your repository. Modify it to match the user you created in that step.

But what if you already have a local repository and all you want is push it and its history to the server?

3.3 Pushing to a new empty repository

What you usually do is creating a local repository, adding file to it and committing this repository history to the new, empty and pristine repository in your web server:

mkdir toyproject
cd toyproject
git init
touch README
git add README
git commit -m 'first commit'
git remote add origin http://username@www.example.tld/corporate-git/toyproject.git
git push origin master

If you have an existing Git Repo, that's the procedure:

cd existing_toyproject_git_repo
git remote add origin http://username@www.example.tld/corporate-git/toyproject.git
git push origin master

The above workflow follows what is presented in http://help.github.com/creating-a-repo/.

4 Final remarks

If you need more than one collection of private repositories (say, one for you and one to share privately with a group of coworkers), all you need to do is:

Create a directory for each of these collections.

Create copies of newgit.sh, one for each collection, and setup the value of GIT_REPOS_ROOT in each of them.

Adapt each .htaccess accordingly.

GitWeb: copy its files too.. Or just sym-link it from a pristine copy.

5 TODOs

Focus on reusability.
Write the Final remarks section properly.

http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html#rewritecond -- serve directly w/ apache if...

Adding project .description directly in the scripts

6 References

Copiando tudo de uma parti��o WBFS pra outra

MaCa — Mon, 25 Oct 2010 23:00:47 +0000

Usando o WIT, Wiims ISO Tools, copiar todas as�ISOs de uma parti��o WBFS para outra � um comando simples como:

./wwt �--update --progress --part �/dev/rdisk1s1 ADD /dev/rdisk2s1

Primeira parti��o (/dev/rdisk1s1) � a parti��o WBFS de destino, a segunda a parti��o (/dev/rdisk2s1) WBFS onde os jogos se encontram.

Homebrews ou jogos j� existentes n�o s�o sobrescritos, ou seja: ele s� copia o que voc� ainda n�o possui.

Para descobrir qual parti��o tem seus jogos, conecte apenas o seu HD e rode o wwt com aop��o LIST-M:

./wwt LM
ScanDevForPartitions(sd)
- part found: /dev/sdt
ScanDevForPartitions(rdisk)
- part found: /dev/rdisk0
- part found: /dev/rdisk0s2
- part found: /dev/rdisk0s1
- part found: /dev/rdisk1
- part found: /dev/rdisk1s0
- part found: /dev/rdisk1s0s1
- part found: /dev/rdisk1s0s2
- part found: /dev/rdisk2
- part found: /dev/rdisk2s1
- part found: /dev/rdisk2s2
- part found: /dev/rdisk2s3
WI �WBFS file
-------------------
1 �/dev/rdisk2s1
-------------------
ID6 � � MiB Reg. �WI �40 discs (105 GiB)
--------------------------------------------------------------------

--------------------------------------------------------------------
Total: 40 discs, 107092 MiB ~ 105 GiB used, 36432 MiB ~ 36 GiB free.

Pronto.

Exporting a git repository to subversion

MaCa — Tue, 06 Oct 2009 20:50:39 +0000

Yeah, you read that right. That is probably the inverse of what most people want. But, anyway, let’s say you have a project originally hosted on a git repository and you need to export it to a subversion repository for some reason. Now what?

The nice folks of Google Code have put a really good step-by-step guide explaining how to do it. This guide was originally posted on Google Open Source Blog. In case you need another view on the process, you can follow the “git export to svn” discussion on nabble — which just get good at the very end.

There is a little gotcha on the guide — not an error, but something they should have stressed. The Subversion repository you will use must be non-empty. Again: the Subversion repository must be non-empty. Notice that by non-empty all they mean is that the subversion repository should have at least one revision commited to it, and not that it ought to have files in it. Got it? Good. Now move on.

Reparo no Time Machine

MaCa — Fri, 02 Oct 2009 03:35:47 +0000

Ent�o, como eu falei antes, enviei o meu Macbook para o reparo, onde trocaram a placa l�gica dele. Depois disso o Time Machine parou de reconhecer o disco de backup antigo que eu usava. Na verdade, ele passa a ignorar todos os backups anteriores e resolve criar um backup novo, do zero. Desnecess�rio dizer que isso tira metade da gra�a em usar o Time Machine (backups temporais), sem comentar os desperd�cio em espa�o em disco — vou praticamente ter duas c�pias dos mesmos dados do disco de backup.

E a�, Bial, como fazer para resolver isso?

Existem bons guias em ingl�s dizendo como resolver; coloquei links para eles ao final desse post. Mas, para aqueles que t�m algum problema com o ingl�s, vamos ao passo-a-passo de como resolver isso na velha l�ngua de Cam�es. Como alguns comandos requerem o uso da linha de comando, vou assumir certa familiaridade com a mesma.

Entendendo o Problema

Antes de mais nada, uma r�pida explica��o. O Time Machine usa um identificador que fica atrelado � sua placa de rede (o seu “endere�o MAC“) para reconhecer o backup de um micro. Isso permite inclusive que um mesmo disco de backup seja compartilhado por v�rios micros: cada um ter� seu backup identificado unicamente pelo endere�o MAC do seu respectivo micro.

Todavia, se a placa l�gica de um micro muda, o endere�o MAC dela tamb�m muda. Por isso, quando o Time Machine for procurar por backups anteriores do seu micro, ele procurar� backups associados ao identificar atual do micro — ou seja, ao seu novo endere�o MAC. E � por isso que ele n�o encontrar� seus backups anteriores: todos os seus backups ainda est�o atrelados ao antigo identificador do seu micro e n�o ao novo. Para corrigir esse problema temos que “informar” o Time Machine sobre essa mudan�a de identificador. Na pr�tica, apenas atualizaremos o endere�o MAC nos backups antigos com o novo endere�o MAC. Assim, o Time Machine identificar� seus backups anteriores como backups do micro atual e nada do seu hist�rico ser� perdido.

Coletando algumas informa��es

Antes de prosseguir, voc� ter� de cololetar algumas informa��es

Mount-point do Time Machine
Provavelmente ser� dentro do /Volumes, alguma coisa como '/Volumes/Time Machine' ou, no meu caso, '/Volumes/Backups do Time Machine/'.
Diret�rio onde o Time Machine guarda os backups antigos do seu micro
Dentro do volume/mount-point do Time Machine haver� uma pasta chamada Backups.backupdb e, dentro dessa pasta, haver� uma (provavelmente) com o nome do seu micro. Essa � a pasta que cont�m os seus backups antigos. No meu caso, o path completo para ele era /Volumes/Backups do Time Machine/Backups.backupdb/notebook
O antigo endere�o MAC do seu micro
Sim! Voc� vai precisar dessa informa��o. Se voc� n�o tinha anotado o seu antigo endere�o MAC em algum lugar o que lhe resta � extrair essa informa��o direto do Time Machine. O comando abaixo deve resolver esse problema. Adapte as nomes dos diret�rios de acordo com as suas configura��es
$ cd /Volumes/Backups\ do\ Time\ Machine/Backups.backupdb/ $ xattr -p com.apple.backupd.BackupMachineAddress notebook
A sa�da desse comando deve ser algo como 00:1e:c2:1e:1e:ca. Esse � o valor do seu antigo endere�o MAC.
O novo endere�o MAC do seu micro
O comando abaixo deve dar conta de lhe fornecer essa informa��o
$ LC_ALL=C ifconfig en0 | awk '/ether/{print $2}'
O resultado deve ser um identificador como 00:22:41:22:16:f3. Esse � o endere�o MAC atual do seu micro.

Passo-a-Passo

De posse de todas as informa��es necess�rias, vamos agora ao passo-a-passo para resolver esse problema.

Se o disco de backup estiver conectado, desconecte-o.
Em seguida, desligue o Time Machine. Voc� n�o vai querer ele interagindo com voc� enquanto os ajustes s�o feitos. V� l� no “Prefer�ncias do Sistema”, v� na �rea do Time Machine e desligue-o.
Reconecte seu disco de backup.
Desabilite temporariamente as ACLs no volume da Time Machine. N�o precisa ficar com cara de Am�lia se voc� n�o entendeu. Apenas digite os comandos abaixo:
$ sudo fsaclctl -p '/Volumes/Backups do Time Machine/' -d
Dentro do raiz do volume do Time Machine existe um arquivo invis�vel cujo nome corresponde ao identificador MAC antigo do seu micro precedido por ponto e sem os “:”, ou seja “.001ec21e1eca“. Esse arquivo ter� de ser renomeado para refletir o valor do novo MAC. Aplique o mesmo processo ao novo MAC e voc� ter� o novo nome para esse arquivo.
$ cd /Volumes/Backups do Time Machine/ $ mv .001ec21e1eca .0022412216f3
O diret�rio com seus backups antigos possui um atributo extendido com o valor do MAC antigo. Atualize-o com o valor do MAC novo.
$ cd /Volumes/Backups do Time Machine/ $ sudo xattr -w com.apple.backupd.BackupMachineAddress 00:22:41:22:16:f3 Backups.backupdb/notebook
Reabilite as ACLs no volume da Time Machine.
$ sudo fsaclctl -p '/Volumes/Backups do Time Machine/' -e
Desconecte/Ejete o seu disco de backup
Re-habilite o Time Machine
Reconecte o seu disco de backup

E � isso. Ap�s tudo isso o Time Machine dever� iniciar um outro processo de backup — e esse deve demorar um pouco mais j� que provavelmente seu micro estava h� um bom tempo sem fazer backup.

Refer�ncias

Reparo no Macbook Pro

MaCa — Mon, 28 Sep 2009 15:23:23 +0000

Meu Macbook Pro estava com um problema estranho: desligava espontaneamente quando passava um tempo apenas na bateria, mesmo essa tendo carga. Bastava um “while true; do echo 1 > /dev/null; done” rodando em dois terminais para, em quest�o de minutos, o mac apagar. Mas apagar mesmo, de n�o voltar at� que fosse ligado no cabo de for�a. E repetindo: a bateria ainda tinha (muita) carga.

Depois de muito adiar levei ele na assist�ncia para ver se resolvia o problema. Antes de mais nada, tenho que dizer tr�s coisas:

Primeiro, Deus salve o momento em que fiz meu plano AppleCare — valeu cada centavo!
Pela primeira vez na vida n�o me senti enganado por uma assist�ncia t�cnica. Gostei muito do servi�o l� da TecMania, aqui em Belo Horizonte mesmo. Recomendo mesmo.
Finalmente, PQP!, Time Machine!

O que ocorreu foi que depois de descartarem que o problema fosse a bateria, que parecia estar normal nos testes, resolveram trocar a placa l�gica (logic board) do coitado. Trocaram e o problema persistiu. Pegaram uma bateria zerada que havia chegado a pouco por l� e tentaram reproduzir o problema. Como n�o conseguiram, deduziram que foi a bateria, e que a minha estava claramente defeituosa. Menos mal, fiquei com uma bateria nova e uma placa l�gica nova sem pagar nada. Digo, tudo pago pelo AppleCare.

Tudo foi bem r�pido. Mais r�pido do que o esperava e quase t�o r�pido quanto eu gostaria. Todavia, depois de ter a placa l�gica trocada, o MBP se comportou um pouco estranho:

O iTunes disse que n�o podia mais tocar as m�sicas da minha cole��o porque n�o tinha permiss�o.
O Time Machine n�o reconhecia os backups antigos que eu tinha.
O VMWare Fusion passou a perguntar se eu tinha movido ou copiado minhas m�quinas virtuais.

O que ocorreu foi que com a mudan�a da placa l�gica, muitos programas acharam que eu tinha mudado de micro, o que n�o foi de fato o que ocorreu. No caso do iTunes foi s� autorizar esse “novo” computador. O VMWare funcionou sem problemas depois que eu disse que “copiei” as m�quinas virtuais. Com o Time Machine n�o foi bem assim…

Massacre virtual

MaCa — Fri, 05 Jun 2009 20:00:46 +0000

Tirar a poeira desse blog com as estat�sticas do �ltimo massacre que eu cometi. Deixei de seguir 21 feeds RSS e de 2 twitters — um deles o do @buscadesconto, que mesmo �til, n�o tem a utilidade que eu esperava). Os feeds que eu deixei de seguir foram:

� uma miscel�nia de blogs de amigos que foram desativados, blogs de programas que eu n�o uso mais e de coisas que, apesar de interessante, simplesmente tomam tempo demais Os canais de video do google, por exemplo: tem muita coisa bacana, mas n�o tenho 1h para gastar vendo-os e cansei de me enganar que marcar para “ver depois” vai resolver j� quem na pr�tica, nunca vejo.

E � isso. Namast�, much love, peace out.

DIY: Base para Lava Lamp

MaCa — Sat, 07 Feb 2009 14:32:15 +0000

Na falta de coisa melhor para postar, vamos tirar a poeira disso com um “antigo” v�deo de minha autoria, sobre como fazer uma base (tosca) para uma Lava Lamp.

Enquanto que uma garrafa de lava lamp custa uns R$ 25 no mercado, a base custa aprox. R$ 100. Isso � um absurdo, visto que a base nao passa de um suporte para a garrafa e uma l�mpada de 40W. Sendo assim, resolvi fazer uma para mim usando uma lata de Nescau 2.0 — e funcionou Custo total inferior a R$ 30, inclu�ndo a garrafa de lava. A lampada que eu usei no final das contas foi uma dicr�ica de 50W.

E sim, eu sabia o que estava fazendo quando eu usei a furadeira

Handbrake novo

MaCa — Thu, 27 Nov 2008 22:16:41 +0000

S� para tirar a poeira do blog — e iniciar uma nova se��o do mesmo. Saiu uma nova vers�o do Handbrake, um probrama para Mac (com vers�es para Linux e Windows) que converte seus DVDs para v�rios formatos interessantes, entre eles os formatos suportados pelos iPod (5G), iPhone, Apple TV, PSP e muitos outros.

De especial a nova vers�o permite agora a convers�o a partir de v�deos em qualquer formato, n�o somente em DVD. Sim! Agora voc� aquele seu amigo pode converter os v�deos .AVI do Family Guy que ele baixou da internet para o iPhone ou para o PSP dele Bom lembrar que esse programa pode ser �til tamb�m para aqueles que querem diminuir o tamanho dos seus v�deos pois ele suporta a codec H.264, que consegue taxas de compress�o muito boas — melhores do que as que se obtem com Divx e similares.

E � isso.

Via Wired Blog: Handbrake Still the Best DVD Converter, Now Handles Any Video Format.

Vida nova a um velho PDA

MaCa — Thu, 16 Oct 2008 18:23:52 +0000

Bacana a proposta de dar vida nova a um velho PDF e transform�-lo em um capenga mas us�vel notebook ou em um eReader.

MAKE @ Digital Nomads – Things to do and make with old Palm Pilots e Giving old PDAs a new life�

In plain English (except the post)

MaCa — Fri, 12 Sep 2008 21:52:03 +0000

Como faz tempo que eu n�o escrevo aqui, eu provavelmente deveria voltar com alguma coisa grande, bacana, para marcar o in�cio de uma nova era (que provavelmente ser� sucedida por outro intervalo sem “posts” por um bom tempo). Devia, mas n�o vou.

Esse post � t�o e simplesmente para apontar para um canal do YouTube que eu achei particularmente interessante: “Explanations in Plain English“. N�o � um blog sobre ingl�s. Na verdade parece mais um “How Stuff works” animado — e em ingl�s . Os t�picos s�o bem interessantes: como as elei��es nos EUA funcionam, o que � RSS, como funciona, para que serve e como voc� pode us�-lo e por a� vai. Tem videos sobre zumbis (?!), wikis, twiiter, social bookmarking e mais. Todos distribu�dos em uma licen�a Creative Commons.

A tem�tica dos v�deos, como pode-se ver pela pequena lista acima, � mais voltada para t�picos relacionados � Internet. O mais bacanas dele � a forma com que abordam seus assuntos: sem tecnicalidades, de maneira direta, clara e acess�vel — do jeito que seus familiares gostam