Hello everyone, I am Shweta, I work under work in IBM, I come from Bangalore, India.
I started work, I started my profession working with GlusterFS, Gluster file system and I
gradually moved on to Glustergeore application and I maintained that for Red Hat.
On behalf of IBM, I started work, I started exploring new projects.
One of them is Samba on Kubernetes.
So here is the introductory talk on the same.
So the title is exploring Samba on various file system.
So bridging ideas and enthusiasts together.
So yeah, let's try to understand what is Samba.
So first of all, you might have heard the last talk or if at all now, then I will just
start from the introduction.
Samba stands for server message block.
It's a protocol used for sharing resources over a network.
So in other words, I can simply say that it is what NFS to the UNIX, it is same to the
Windows word.
So both are different protocols.
And NFS stands for network file system.
So this is basically the same.
We can share the resources over a network.
That is, user on a client can access the file, as if he is accessing the file from a local
storage.
So these are the two terms that we had to be aware of.
So next, so we just came to know about two different protocols used by Windows and UNIX
systems.
Now, here comes a question.
So what if we want to use two different operating systems in the same network?
What if we want to share a same resource with a Windows server and a Linux client or a Linux
server and Windows client?
We know they use different protocols for communication.
That is, it's just like they speak two different languages.
Now how can they communicate with each other?
So this was the problem statement that Dr. Andrew Trigel found interesting to work on.
So he just wanted to connect his UNIX server with his wife's Windows machine.
So he just started exploring what is SMB.
He wrote a packet sniffer.
With this packet sniffer, he could analyze what is going on in this network, at what
frequency the packets are passed, what he could also intercept the logs and understand
what is the pattern in which these data packets are traveling in the network.
So with all the insights he got from this network sniffer, he just wrote a software
that could help make his UNIX server look like a Windows server so that Windows client
could access files from a UNIX server.
So basically this turned out to be a project where it was an inter-polarability project
where a Windows system as well as a UNIX system could communicate with each other and share
the resources together.
So here, majorly he could solve his own problem of sharing his house printer with his wife
who was owning Windows PC.
So this is how the project Samba was born.
He just wanted to use the words SMB, the server message block, and create a word.
That was Samba.
Now let's come to the implementations of it.
So firstly, how Samba is set up with file system.
So here you can see that we are talking about a clustered file system.
So these are basically the server and each server is installed with file system.
It can be cluster, CFFS or any file system.
And as you know that they are clustered, that means they are internally connected with the
private network.
They might be following their own principle for that.
And once we install this file system, we will be installing CTDB on top of it and we will
be configuring this CTDB.
CTDB is nothing but a clustered TBD, clustered trivial database.
It is basically written for Samba.
It stores some of the temporary data that is used by Samba.
This could be information about leases, logs, or some IP addresses and such stuff.
And it also will make sure that all this data required by Samba is highly available.
So that is basically the work of CTDB.
And upon CTDB, we will have to configure Samba.
So in Samba, you will have to configure a share, username, user password, etc.
Share will be nothing but a mount which you will be using and where the resources will
be.
And user and password are necessary because this Samba can also act as domain controller.
That is it can control the security-wise decisions.
Like which user can I allow to access this resource?
So that is what it is doing.
And next, okay.
So we just learnt what is Samba and how it is installed and how it works with the FILE
system.
So basically it is a business solution.
So we know that in an enterprise level solution, we do not see that only Unix servers or only
Windows server communicating with each other.
So there can be a lot of clients.
There can be a Windows client, there can be a Unix client.
Everyone trying to communicate or everyone trying to use the resource from a particular
server.
And they can be again Windows or Linux.
So in this case, SITE is an Test Integration Environment that is basically set up to test
this Complicment Setup of Samba.
This will include a lot of servers, a lot of clients and a lot of projects like maybe
GlucidFS, CFFS, CTDB or Samba itself.
And it can also include multiple configurations of Samba, multiple configurations of FILE
system.
So it was very convenient to automate this.
If we might spend a lot of manhours to manually create this setup.
So this was very convenient way for us to create an automated environment.
So any system that has the softwares like Vagrant, Libvert and Ansible can help you
run this project.
That is SITE environment.
And we might need a minimal resources like 2 to 4 GB for storage VMs and a minimum 1 GB
for other VMs.
We can also have other VMs which act as clients or which contain the scripts that are required
to run this test.
So also we can use this, as I said, we can use this for creating custom Samba environment.
We can experiment stuffs on it.
Basically it can create your Samba playground.
You can play it with it, you can use your favorite file system, you can write your favorite
test or you can manually go and run some commands and learn more about Samba.
And apart from this SITE environment is used for periodically triggering the test we use
nightly runs and also whenever there is a new change in the project, this SITE environment
runs the SITE test cases.
So it is like, it progressively checks that all the components that are involved are in
sync.
So we are not encountering any issues before it is given to the user.
Before getting to the user we make sure that everything are working in sync and there are
no issues among them.
So also we are using the most recent code from the main.
So that means that it is always, we make sure that the main is always compatible with all
the projects which are involved are compatible with each other.
So now why SITE?
So I said, I said to you that we will be using the file system and these file system like
maybe say a safe file system.
So this, the resource, the file shared by it is not only used by a Linux system, it can
be used by Windows system as well.
So that is exactly the use case where SITE came up.
So with SITE we can very easily configure this file system, not just whatever, we can
just configure for safe, we just configure for Glastor Dive, whatever file system we
can configure the number of servers, number of clients and we can make our environment
ready for testing.
With this we can also find out compatibility issues within Samba and file system and also
we can find about bugs and unexpected behavior of the file system and issues in Samba.
And now what are SITE test cases?
I had briefly told, I had just mentioned about this.
So this is basically a GitHub repository.
This is run by SITE environment.
It houses number of tests.
So currently we have consistency test, container test, miscellaneous test and SMB test.
So the consistency tests are just mounting the share, writing the data onto the share
and unmounting it.
So we will just make sure that the exact data is written and read.
And the container tests are, it is just exploring the possibility of running these tests on
a containerized environment.
So we just need to write more of these tests.
So we have still scope for improvement in this.
And miscellaneous test, these are the IO based test.
We have basic IO like read, write.
We have a database IO where we import a database and simulate a database related input output,
maybe like querying from the DB, storing the data in the DB, etc.
And then we have a stress IO, which is we are creating a lot of stress with the large
GB of data and we are just testing stress load on the system.
And lastly and most importantly, we use SMB test.
These are part of SMB torture.
These analyze the packet level rules and regulations.
So these also have this SMB1 test, SMB2 test, which is nothing but CIFS test.
And also they test this RPC level compatibilities or incompatibilities and whatsoever.
Now how does SIETE works?
So as I have already told, we use LibWord and Zibliu might have already guessed we will
be dealing with the virtual missions.
So a host mission will create number of virtual missions and these can be servers, clients.
So basically this is a screenshot from virtual mission manager.
So these were the missions created by a basic setup where client 0, setup 0 and storage
0, 3 VMs were set up.
Setup 0 basically contains the Ansible script.
Storage 0 is the machine which stores the file system.
It is the server where file system is imported.
Client 0 are the, this is the client from which we access the files.
So as it is an automation, so we do not have a lot of things.
I will just explain how it is, what, yeah I will just explain you what happens during
this automation.
It is very simple, we just run a make.
So with the default file system like XFS or whatever we set as default will be setup.
The vagrant VMs are setup and then inventory is created.
So we can see that client 0, client 1 and setup 0 was setup.
And then as a, yeah so we install the Ansible, we install the packages that are required by
the file system on the server.
And also yeah we have this configurations related to SSH and also all the back and specific
tasks.
We set up the permissions.
I just move forward quickly.
Yeah we also have to deal with the SNX permissions.
Yeah finally once all the packages are set up like CDB setup, Sambai setup, we will run
the test from the SID test cases.
So yeah these test results will be present in test.io out and you can examine them.
So I will just move on to the next slide.
Yeah this is a very, it is a pretty simple execution.
We just run make and let me move on to the next slide.
So we can list the virtual machines that were created with the worst list.
So these are the machines.
You can even, we can stop this and we can even SSH to them and manually use this as
a playground for our executions.
As of now I am just showing you the automation stuff.
So yeah so we just run make clean that will destroy the VMs once we are done with the
things once all the automations of tests are done.
So it just destroys the VMs and we get back the clear end environment again.
So we see that no VMs are left.
So this is basically how we can pass the extra variables like which OS you want to use, which
file system you want to use.
In this case we are using a GlucidFS file system and there are the file system specific
tasks that are taking place and we download the recent code from GlucidFS and we use basically
the same things that are taken in the first demo will be taking place specifically for
the GlucidFS file system.
Obviously it was for XFS and now there will be different, sorry.
So this will be just different, difference will be just in the creation of setup of
server.
But then everything will be similar.
We also check if the cluster is in a healthy state and we also as I said you can just recall
our installation of file system, CTDB and Samba.
So that is basically done here.
Yes so now about custom backends and tests.
So now do you want to add your favorite backend or file system to SIT environment?
As of now we support XFS, GlucidFS, CIFFS but we also have scope to add in more and
more backends.
So how will you do it?
So the first thing we will have to define a background.
So you will include, it is basically the Ansible script.
You will have to make sure that how many missions are needed and what test you want to run on
them.
So basically declare them.
That is called as defining the background.
Then next you will have to know what are the installations you need, what are the packages
you would need to install your file system.
So that will be the next part you will have to decide about.
And then finally you will have to create the backend role which will actually include the
steps required to set up the file system and make it work on your machine.
And then we will have to configure CTDB, then you will have to configure Samba.
So a detailed description about it can be found in docs backend.
Then do you want to add the custom test to this project?
You can add any of the, there is a docs test.
You can refer to that and it explains in detail how this can be done.
As of now we have a project SIT test cases that is also a repository on GitHub.
You can just add your test and get it merged and that automatically runs this test on SIT
environment.
Yeah, this is it.
So this is the reference.
So yeah.