XigmaNAS

All,

I created a working NFS + HAST installation in my VMWARE lab where I had two full installations. Now that I got everything working I'm installing two physical servers with enough disks to do more thorough testing but they are both booting from usb sticks and as such I installed the embedded version. After making the necessary changes and config I moved on to editing the carp-hast-switch script and lo-and-behold after rebooting my config was GONE. After realising the embedded install doesn't permanently write configfile changes to disk I'm wondering how I can get this done.

The change to the file only consists of about 10 extra lines so it would not be an issue regarding diskspace or whatever other reason the configfiles can't be changed in the embedded version.

Please help.

sorry 4 a stupid question: r u sure it was embedded not live?

save your config on youd data discs.

then use
http://wiki.nas4free.org/doku.php?id=do ... []=scripts
to copy the file where you need it.

Thx for the answers but none are usable.

Since the datadisks are used in a HAST setup with ZFS on top, and they get imported exported on CARP events, they can't be used to save the config files because on the backup machine the pool is unreachable until it becomes master again.

Any other suggestions?

Format second partition of your boot disk in UFS and use to store data.

If not posible, try to do a full install, save config in a safe place , and in case that your boot disk, burn, use new one and restore config, or use some kind of DOM to avoid premature burning of your USB key. (Full install solve your lost of config)

Right, how is anyone supposed to help make nas4free better if we have to use workarounds to even change basic config files on an embedded version. Embedded is exactly the right way to go because you save valuable space and ports in your chassis. Since Nas4Free didn't support HAST + NFS and took the liberty to research it and created adapted scripts but just to save them is a hassle. I understand the need to make the embedded usb read only because of limited lifetime of the usb storage chips, but how about making it writable on request by a button or something to be able to change at least basic config stuff that's not in the gui.

I'll try the workaround but in my opinion this is NOT the way to do this.

I agree, but keep in mind that embeded was focussed / designed for normal users with simplicity in mind , for advanced users ( HAST / CARP is for advanced users) the full install is the recomended way ( okay , this involve not to use a cheap USB key) but If you need professional / advanced features, use professional boot disk ( use DOM or IDE Disk if your board support it, etc...).

PD: I see your lattest post and I see a great work on HAST/CARP, are you interested on reflect your experience in a post to help others users in tha same situation?.

Writting a guide / tutorial is really needed for HAST /CARP actually.

Posting your script, help too.

raulfg3 wrote:I agree, but keep in mind that embeded was focussed / designed for normal users with simplicity in mind , for advanced users ( HAST / CARP is for advanced users) the full install is the recomended way ( okay , this involve not to use a cheap USB key) but If you need professional / advanced features, use professional boot disk ( use DOM or IDE Disk if your board support it, etc...).

PD: I see your lattest post and I see a great work on HAST/CARP, are you interested on reflect your experience in a post to help others users in tha same situation?.

Writting a guide / tutorial is really needed for HAST /CARP actually.

Posting your script, help too.

As I said in the other thread about HAST/CARP I'm allready commited to writing up a HAST+CARP+ZFS+NFS/iSCSI [How To] but first i would really like to get an embedded version running with the modified scripts. I see embedded as a necessary medium because:

1. speed, booting everything to RAM makes for a snappy system
2. save SATA/SAS/IDE ports for where you really want to use them -> STORAGE
3. why burn money on an expensive boot disk (SSD/DOM/HDD) when a 15$ high quality USB stick can get the job done (if set up properly)
4. default config on reboot, actually that is exactly what is best for most users, however the lack of ability for the advanced to make changes is ... well it sucks ...

Once I get an embedded system running with my modified script(s) I will definately share it all in a well documented (screenies/video baby!) how-to.

Just a little update :

I'm using http://wiki.nas4free.org/doku.php?id=do ... om_scratch as a guideline and am in the process of building my own version of the Nas4Free image. I'm not there yet but at least I'll be able to create/edit the necessary files. If anyone has other options I'm all ears!

Right I'm giving up on de custom embedded image. Can't get it to work properly, and don't have enough time to research it all. If anyone could point me to soemthing that would allow me to easily insert my modified scripts in an embedded image of the latest release that would be great.

Here is a nice and simple solution:
http://barbz.com.au/blog/?tag=bsdnas4freefreenas

I have the same problem and I'm going to try it myself.

Another more complicated option is defining Jail (google it).
There's a tool called TheBrig that supposed to make Jails management in nas4free simpler, but it is still a hassle.

Good luck!

When you talk about config files I gather you are talking about files in /etc and not the config.xml. If you look at the init scripts you will see that the config files are rebuilt from the xml file each reboot.

From the IRC bot.

If you're trying to reconfigure your NAS4Free install by way of the CLI, you're
doing it wrong. Almost all the settings that NAS4Free uses should be changed from GUI. Almost every
change that you might be making to the system will be lost on reboot.

Even restarting a service will cause the config files to be rewritten so be careful if you just copy over the configs, you may need a post init script to copy over the config file and a custom rc.d script for the service you are modifying.

If I'm talking about the wrong "config" files then please ignore this post

Also, note that you can write to the USB drive. It is mounted RW, but you can mount /cf RW and have write access. The space there is very limited, and it may not get you what you want, but it is there.

What you might want to do is step back and look at how you are architecting this. Perhaps discuss that design here. It sounds to me like you are fighting the reasons the embedded image was developed, instead of working with them.

Lee Sharp wrote: What you might want to do is step back and look at how you are architecting this. Perhaps discuss that design here. It sounds to me like you are fighting the reasons the embedded image was developed, instead of working with them.

I agree.

Thx for the latest replies,

haven't played with it because I'm working on a big project right now. But what I need to change are first an foremost the scripts that handle the failover of the carp en stop/start of related services. This can not be changed on the embedded install. And exactly that should be able. It's only one script that needs a couple of lines of code added and permanantly to boot. And to use one of the workarounds would mean the bootup time/failover time between nodes would increase just because you can't modify the preinstalled failover script?

Suggestions welcome ofcourse!

What do you need to change and why? I mean, if it is that handy, it might just get rolled into the image for you.

I made some adjustments to the script to add failover of NFS, in the default script only iSCSI is supported, but since NFS is more and more popular along with vSphere, NFS is a much needed protocol. So I added a couple of lines to the script to handle the failover of NFS. Still a work in progress though, since it's not working everytime, but as I'm working on a big project, time is scarce.

All the more reason to open this up. I too see NFS is a key component of fail-over. I am sure others will as well. If you start a thread outlining what you are trying to do, and share the code you have so far, I bet others would get involved and help out.