Free Online Registration Required

The tutorial session you want to view requires your registering with us.

It’s fast and easy, and totally FREE.

And best of all, once you are registered, you’ll also have access to all the other 100’s of FREE Video Tutorials we offer!

 

×
Podcast
×
Transcript

Solaris 11 ZFS Share Demonstration

Just out of interest, Solaris 11 also supports CIFS which is Microsoft file sharing by the server and client instead of using Samba. This support is built in, and that will be covered in the full 5-day transition course.

 

As far as NFS is concerned, things have changed a little bit. You might approach a Solaris 11 system, log in as a root and try sharing file systems and find it doesn’t work in the same way that you’re used to in Solaris 10, which can be a little bit annoying and frustrating. But bear with it because although facilities have changed, it’s not a great deal extra to learn and you will also notice that things have improved a little bit too.

 

[pause]

 

Another key feature in Solaris 11 is that zones, Solaris containers, if you like, can now be NFS servers, which was not possible in Solaris 10. 

 

As far as sharing ZFS file systems is concerned, there are two stages involved rather than the single stage in Solaris 10 where you have to set the sharenfs property. That is still the case with Solaris 11, but the actual share details the machine is with which the share is being shared, for example, are now contained within the share property for ZFS dataset. Please note the /etc/dfs/dfstab file does exist but is no longer used.

 

[pause]

 

If you’re in a bit of a hurry and you want to share NFS file systems quickly, you can actually do it with the share command.  

 

If I create a pool, if you look on the right-hand window, I’m logged into a Solaris 11 system here, which is actually a logical domain. I’m going to create a pool.

 

[pause]

 

Then I’m going to create a file system or, if you like, a ZFS dataset within it called data 2. Then I’m going to share it without changing any of the properties and without previously having NFS enabled. 

 

[pause]

 

Notice how I put the mount point name rather than the pool name. 

 

[pause]

 

If I now type “share” I can see I’m sharing /lake/data2. 

 

[pause]

 

There I can see the mounts. Also, the appropriate system service known as NFS/server is running online. 

 

That makes life nice and easy. In fact, the share properties have actually been set within the dataset.

 

[pause]

 

There we go. ZFS get share lake/data2. You can see that the share property is set. Rather complicated-looking set of share options, but we’ll see how to set them very shortly. 

 

I can also unshare. Notice I’ll have to use the proper Solaris path for that rather than the dataset name. If I do a ZFS get again, that’s now gone. However, the NFS service is still running although it’s not sharing anything.

 

That’s one way of doing it. But if you like, the proper way is setting the property share yourself. This is how Oracle recommend that you do it. The share command is really just put there for compatibility.

 

If I set ZFS set share=name=data2, the name doesn’t really come into it by the way. It’s the path that we’re interested in. Path=/lake/data2,prot=nfs (the protocol). Bear in mind that we could also be sharing using CIFS, and in fact we could share both at the same time. In this case, we specify the dtaset name.

 

[pause]

 

You have to remember when to use the mount point and when to use the dataset name. There you could see the information being printed back.

 

[pause]

 

Generally speaking, if NFS wasn’t running, the sharenfs property wouldn’t be set. But business we use the share command earlier, in fact, the sharenfs property which determines whether the share can be seen should be on so that share should be available, which it is. Normally, the sharenfs property would be off, so we have to set the sharenfs property as you can see on the left-hand side here. I set on. That would publish the share. It would make it available. So the share would not be available until you do that. Then we can get the property as you can see on the slide and also over here.

 

[pause]

 

There are numerous other things you can do. You can unpublish a share so that the share property still remains but the thing won’t be shared.

 

[pause]

 

Nothing shared, no sharenfs. But the share property will still be the – as you can see. So it’s now a two-stage process. Set the share property and then publish the share by setting the sharenfs=on. The nfs services are then providing that share.

 

[pause]

 

You can remove a share if you look on the left-hand side here. You can remove a share with ZFS set-c share=name=data2. That’s actually removing all the properties from the share. You can remove individual bits which we’ll see shortly. 

 

Of course, you can set complex shares where you’re deciding perhaps who to share with. Here’s an example that most people will be able to relate to their experiences on Solaris 10. Set the share name, set the path, set the protocol, which is what we did before. But this time, we’re defining the machines, the hosts that can actually access the share by putting comma rw (read-write) for buzz:woody:lotus (which are three other hosts), root=woody (would allow the root, the administrator to command on woody root access to that share). Finally, the dataset. 

 

[pause]

 

It’s a little bit more complicated, slightly different format. But we’re all on familiar ground here because we all have experience to this on previous Solaris systems. It’s just getting used to the new syntax.

 

[pause]

 

There are some more examples on the next page. You might be wondering, “Can I share to all machines on the network?” At the top there, there’s an example using the @ notation.

 

[pause]

 

Then the second example is something that a lot of Solaris administrators will want to do when they’re sharing things like Solaris distributions. That is making the share available as a root but in read-only mode using the anon=0 facility.

 

Lastly on the page I’m setting a share to remove the property anon=0. So slightly different syntax to what you might be used to, but nonetheless a useful example if you go to try on the Solaris 11.     

 

[pause]

 

NFS sharing inheritance comes in a little bit and it’s quite confusing, so I just want to spend a couple of minutes talking about that before I finish the presentation. 

 

When you create a new share, usually it’s not inherited unless the sharenfs option is set to on. Let me give you an idea. If I start creating this dataset – I’ll do a destroy on the dataset we previously existed, I’ll need to use the correct command. Then I’ll create the pool again.

 

[pause]

 

Then I’ll create some datasets within the pool. 

 

[pause]

 

Then I’ll create some datasets at lower levels.

 

[pause]

 

We’ll have a look at the share property. 

 

[pause]

 

Everything is off. 

 

[pause]

 

We’ll have a look at the share as well the sharenfs. Nothing there. The sharenfs is off, no shares.  Now we’ll set a share on lake/data2.

 

[pause]

 

Same as before but we’re going to do it slightly more complex this time.

 

[pause]

 

I’m sharing with my three machines – let me just move that over a little bit – buzz, woody, and lotus. I’m giving root access to woody on lake/data2.

 

If I like to get -r share again. 

 

[pause]

 

I’ve set on lake/data2 but it’s not been inherited by the lower datasets. The share properties as you would understand have to be set individually on those lower-level shares. It wouldn’t be very good if you just did a blanket set on all of those things. 

 

[pause]

 

The sharenfs property is still off, so the share isn’t published – although the share is set.

 

[pause]

 

Let’s see what happens if we create a lower-level new dataset work3. And then look at the share again. Nothing set for the new dataset either.

 

[pause]

 

Now if we share the dataset – if we publish the share, we can zfs set sharenfs=on lake/data2. 

 

If we do another get that file system is now shared, but the lower-level datasets aren’t. However, with the sharenfs property on – by the way, of course we could set the share properties and set sharenfs on to the lower levels too. 

 

Have a look at this. If I now create yet another lower-level dataset and do the get -r once more, that has now been shared. And the share details are different. They haven’t been inherited from the high-level dataset. There’s a new share that’s called a default share that the system has automatically set up for us. That’s known as a default share.

 

There we go. Things have changed a little bit in Solaris 11, but I hope that’s given you a bit of a practical idea of how to get NFS up and running and some of the little twists that I provided now in terms of sharing datasets and understanding how inheritance works. That’s all for this part of the seminar. There will be a part two available which will look at the other ZFS features. Thanks for attending.     

Copyright SkillBuilders.com 2017

×