Ceph Internship – Week 4.. beep beep.. Updates comin

Okay I realized how clumsy I was when I wrote my first blog. That was actually level zero like Po in Kung Fu Panda. Well, this is how we learn and grow. It’s been around 4 weeks that I’ve been working on Ceph and it’s making me more and more curious how things actually look when I run a bunch of commands that I totally didn’t understand a few weeks ago. It took me a while to get used to the mounts and users functionality that’s built in Ceph. The documentation for Ceph gave me a great deal of information to get things setup. To get started with, I first moved to the src/ directory within the ceph/ repository and triggered a make command:

cd src/ make

Next step is to get the cluster up. In particular, you have to do a vstart providing parameters like the number of monitors, OSD servers and MDS servers to setup. The -n parameter specifies that you are setting up a completely new cluster and that every other infrmation that was stored in the previous cluster that was up would be lost (For instance, set up clients or associated keys)

MON=1 OSD=1 MDS=1 ./vstart.sh -d -n -x -l

To stop the server, just run:

./stop.sh

TIP: If you wish to verify the state of your cluster, you can run the following command which would give you info of the number of monitors, OSD servers and MDS servers that are up and running:

./ceph -s

Mount as admin: Mount requires you to specify the client you are mounting as. Each client has an associated key with a set of caps which determines how the user would be interating with the Ceph File System while he/she is mounted to a particular directory (For instance, mds caps would govern access permissions). By default, there is already a client which is “client.admin”. If you wish to see what information is associated with client.admin, run the following command:

./ceph auth get client.admin

The output would be something similar to this:

*** DEVELOPER MODE: setting PATH, PYTHONPATH and LD_LIBRARY_PATH *** exported keyring for client.admin

[client.admin] key = AQA/MZRVdVe7ExAAS+OGSc+Uh5oifXJzp/2oNw== auid = 0

caps mds = “allow *”

caps mon = “allow *”

caps osd = “allow *”

The key can be different. Now if you wish to mount without creating a new user, just specify a path where you have to mount and run:

sudo ./ceph-fuse <PATH_TO_DIR>

Now you can change to the directory and start making files and directories or read them.

P.S. You have to be sudo while mounting

Mount as a new user: If you want a different set of permission, you can create a new client key and assign a new set of caps to it. This can be stored in a file for import while the server is up:

./ceph-authtool -C keyring.foo -n client.foo –cap osd ‘allow rwx’ –cap mon ‘allow rwx’ –cap mds ‘allow rwx’ –gen-key

Now the new set of client details is in file keyring.foo. You can check it out. The next step is to import it so that the cluster knows the new client details:

./ceph auth import -i keyring.foo

That’s it! Now you can mount as client.foo using:

sudo ./ceph-fuse <PATH_TO_DIR> -n client.foo -k keyring.foo

Now if you wish to unmount, run:

sudo fusermount -u <PATH_TO_MOUNTED_DIR>

That’s all folks! I hope that was useful.. And I hope I got better at blogging 😛 Don’t know about that actually!

Advertisements

One thought on “Ceph Internship – Week 4.. beep beep.. Updates comin

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s