Hey everyone and welcome back.
So now what I want to talk to you about is the installation of SAMBA.
Now to actually begin, what we will do is go directly to the command line, okay?
So what we'll do here is I will say sudo and I will say apt.
And what I'm going to install is SAMBA, which will give us the functionality of the SAMBA
server.
I will also say SAMBA-CLIENT.
Now one word, the SAMBA client typically is going to be installed in your system, but
in the event that it is not, you can install it using SAMBA-CLIENT.
And the last thing I want to install is a program, which is going to be used by both
the SAMBA server and the SAMBA client, that is going to be SAMBA-COMMENT.
So if I hit ENTER now, oh and notice actually, it might actually be renamed to SMB-CLIENT,
just to be aware of that.
Let me just say yes.
And now we have everything we need installed.
Now before we actually begin working through the configuration of SAMBA in any great detail,
let me just discuss some of the concepts that are going to be related to this subject.
One of the things that we're going to be encountering is how SAMBA actually handles security.
Now in real terms, we have to be aware of two different types of security implementations.
And when I'm talking about security, what I'm talking about really is how we can securely
authenticate with our SAMBA server so that we can get the information that we need off
of that server.
So the first type of security is going to be referred to as user security.
And this is going to be the default security that is used.
And honestly, this is going to be the type of security that I'm going to recommend you
implement.
It is a default for a reason.
And we certainly will see this type of security later on within this skill.
Now the second type of security is just referred to as share security.
I'm really not a fan of this type of implementation.
And I think you maybe see why when I explain it.
So let's talk about the differences between them then.
So when we're talking about user security, this to me just seems really quite natural.
It is when you happen to provide a username and paired with that username is a particular
password.
This is just like logging in to many different websites.
You know, maybe you've got a Reddit account or maybe you have a YouTube account.
You type in your username and you authenticate that with the actual password.
So by providing both, that is how you get access.
This is effectively what we're talking about when we're talking about user security with
respect to SAMBA.
When we're talking though about share security, things are a little bit loose or at least
looser.
And all we really require here is a password.
So you can kind of more conceptualize this as having some type of folder on your system
and the access to this folder is protected with a password.
So notice here, we actually are not concerned with providing a valid username.
Simply put, if you know the password to the folder, you can access the folder in the same
type of deal as with respect to SAMBA here when you're implementing share security.
If you happen to know the password for that share, then you may be granted access to that
particular share.
Now, here is an issue and it really is an issue in how Linux actually operates.
The way Linux actually operates at its fundamental level, it really does enjoy having this combination
of usernames and passwords.
This idea of just having like a password protected folder, not really how Linux likes
to authenticate.
So the idea that we do not have a username presents to us a little bit of a challenge.
So here is how this is actually going to be resolved and it is resolved in a kind of novel
way.
And again, I'm not too much of a fan of this.
It's on our SAMBA server.
Let's say this is a CROK.
So this is the SAMBA server.
And let's say we have some type of share that we want to be shared.
So this could be some type of directory on the system.
Just call this directory X.
And within this folder X there is some really useful information that is going to be shared
amongst the team.
So what we actually do at the share level is we're going to specify the users, which
happen to be allowed access to this particular share.
So we define this on the server itself.
We maybe say, you know, John and Bob are allowed access.
And then when either John or Bob try to actually gain access from their computer over here,
when they go in and try to reach that share, the only thing they have to provide is their
password.
They do not actually have to provide the user name John or the user name Bob.
Instead that information is going to be held over on the SAMBA side as a list of allowed
users who can actually use this particular share.
Now the interesting thing is that SAMBA is only going to be checking for this particular
password.
So really if let's say Bob was trying to access the share and let's imagine that John
is a very lazy computer professional, he happens to leave his password on a piece of paper
next to his desk, which you absolutely should not be doing.
But Bob can actually see John's password.
Bob could just type in John's password.
Let's just say John's password was John1 because apparently John is super lazy with security.
And Bob actually could authenticate with this SAMBA server because he would be on the
list of allowed users, Bob.
And the only thing SAMBA would be checking is the password and the password John1 is
an allowed password for this particular share.
This would ultimately grant Bob access to the SAMBA share even though he happens to
be using John's passwords.
Hopefully that makes sense.
But as you can probably sense, this doesn't sound too robust.
This is indeed why I'm not a big fan of this type of implementation.
And it is the reason that it is not the default way to protect your SAMBA shares.
Now with respect to our SAMBA configuration, we actually have a configuration file and
it's this configuration file that is whereabouts we can actually specify the type of security
that we want to implement.
And honestly, it's this configuration file that is going to control everything we really
do with respect to our SAMBA server.
And this happens to be located in a very particular location.
This is going to be in the Etsy directory.
And then within that, we will have a SAMBA directory.
And then within that directory, we should have a file called smb.conf.
This is going to be the configuration file that you can expect to use.
However, if you happen to be using an older system, the actual location might even be
in Etsy, forward slash smb as opposed to SAMBA and then smb.conf.
However, like I say, this happens to be rather antiquated.
You should not expect this to be the default location if you are on a modern system.
For the purposes of the examination, just be aware that these two different locations
do exist.
But in real terms, you can expect your configuration file to lie within the SAMBA directory.
So now that we have some of the bare bones basics behind us around the concept of our
SAMBA server, how about we actually dig into this configuration file to see some of the
details of how we can actually get this server up and running.
And well, that's what we're going to be doing in the very next nuggets.
I hope this has been informative for you and I'd like to thank you for viewing.