FreeNAS Startup script?

[norbs]

I'm using freenas in a lab environment and what I am trying to do is get ESXi to rescan for iSCSI datastores right after FreeNAS boots. I set up ssh key authentication to the ESXi host so that FreeNAS has shell access without a password. Now I simply need to run a one like command on the FreeNAS box (which in turn calls it on the ESXi box) but I don't know a good place to drop the command into.

Is there a script in freenas that runs almost at the end of freenas boot? Better yet, a script that runs after iSCSI service is started?

Basically looking to run this once iSCSI is available:

Code:

ssh root@esxihost 'esxcli storage core adapter rescan --all'

or

Code:

ssh root@esxihost 'esxcli storage core adapter rescan --adapter iSCSIadaptername'

The reason I am doing it this was is because if an esxi host boots while an iSCSI device is not available, the host does not automatically reconnect the luns after is becomes available.

 

[SweetAndLow]

You can run scripts post startup under system settings in the GUI. Does that work for you?

 

[norbs]

Not really... main purpose of this is that I'm looking to automate as much as possible.

 

[Ericloewe]

I believe there's an option for this. Have you checked the manual?

 

[norbs]

Not yet, I'll have to check that out; I only searched the forums.

I'll share what I find if I do figure it out.

 

[Ericloewe]

6.2 - Init/Shutdown Scripts

 

[Bidule0hm]

It's called post init scripts and it's in the manual ;)

Edit: well, Ericloewe has been quicker...

 

[norbs]

Thanks, both you guys. I'm pretty sure this is exactly what I need.

You guys rock. :)

 

[SweetAndLow]

You can run scripts post startup under system settings in the GUI. Does that work for you?

huh? isn't this exactly what i suggested and norbs said that wasn't what they wanted?

 

[norbs]

huh? isn't this exactly what i suggested and norbs said that wasn't what they wanted?

I totally misunderstood what you meant.

For some reason I thought you meant for me to launch the GUI each time and run the script I made from the shell prompt. I was kinda confused why you were telling me to do that... lol thanks anyways.

 

[SweetAndLow]

ok good, i was on my phone so didn't have the environment to give a full proper reply. Next time I'll make sure to be more clear.

 

[m4rv1n]

Hi,
I 'm in the interface and try to use startup script, type is command and when is post init.
When I try to save with ok, I receive this error "Error: attempt to write a readonly database"
Same error if I try to modify other task like S.M.A.R.T. test.
The fs show read-only mode.
Freenas release is 9.3 last update today.

freenas-boot/ROOT/FreeNAS-9.3-STABLE-201504152200 on / (zfs, local, noatime, read-only, nfsv4acls)
devfs on /dev (devfs, local, multilabel)
tmpfs on /etc (tmpfs, local)
tmpfs on /mnt (tmpfs, local)
tmpfs on /var (tmpfs, local)
freenas-boot/grub on /boot/grub (zfs, local, noatime, nfsv4acls)
zvol on /mnt/zvol (zfs, local, nfsv4acls)
zvol/.system on /var/db/system (zfs, local, nfsv4acls)
zvol/.system/cores on /var/db/system/cores (zfs, local, nfsv4acls)
zvol/.system/samba4 on /var/db/system/samba4 (zfs, local, nfsv4acls)
zvol/.system/syslog-ffb84ccc300c4843b1352f93d2beb43e on /var/db/system/syslog-ffb84ccc300c4843b1352f93d2beb43e (zfs, local, nfsv4acls)
zvol/.system/rrd-ffb84ccc300c4843b1352f93d2beb43e on /var/db/system/rrd-ffb84ccc300c4843b1352f93d2beb43e (zfs, local, nfsv4acls)


EDIT:
Finally is because I use SD card for freenas root, so is in readonly mode. To solve:
- Mount filesystem in RW with mount -uw /
- Alter setting you want to
- mount -ur /

 

[cyberjock]

EDIT:
Finally is because I use SD card for freenas root, so is in readonly mode. To solve:
- Mount filesystem in RW with mount -uw /
- Alter setting you want to
- mount -ur /

Yeah, if you are using an SD card for FreeNAS' boot device, it's a matter of time before you kill your config file, the boot device's file system, or both. The manual doesn't recommend SD cards because they are a very poor choice for FreeNAS boot devices.

 

[m4rv1n]

Yeah, if you are using an SD card for FreeNAS' boot device, it's a matter of time before you kill your config file, the boot device's file system, or both. The manual doesn't recommend SD cards because they are a very poor choice for FreeNAS boot devices.

How much and what freenas write on boot device?

 

[cyberjock]

How much? Well, I got about 10 minutes on my system before it started acting weird. Later one of the FreeNAS devs figured out it was because of the SD card. Card works great in my digital camera. Just can't use it as a boot device.

 

[anodos]

How much? Well, I got about 10 minutes on my system before it started acting weird. Later one of the FreeNAS devs figured out it was because of the SD card. Card works great in my digital camera. Just can't use it as a boot device.

My experience with SD cards is that they come in two varieties: crap and flaming crap.

 

[m4rv1n]

How much? Well, I got about 10 minutes on my system before it started acting weird. Later one of the FreeNAS devs figured out it was because of the SD card. Card works great in my digital camera. Just can't use it as a boot device.

The question is how much freenas write and what file; time of your card, with all respect, is not relevant because you question about the card and not about the OS's write.
Today we are talk about card that are big and support good number of write. All esx system run perfect on sdcard so the question about work with freenas is relative to numbers of write.
If a card work in a phone for 1 year, can work in a system with few write, but sure we need someone that can tell how much freenas write to boot partition (sure apart update).

 

[cyberjock]

The question is how much freenas write and what file; time of your card, with all respect, is not relevant because you question about the card and not about the OS's write.

Do you think that I've somehow overlooked this very basic concept?

It doesn't matter how much FreeNAS writes and what file. That is not the problem at all. The problem is that SD cards, as a technology, cannot handle random read and/or random write workloads. ZFS hPERIOD. The technology was not designed to handle that workload properly. Even real bonafide USB sticks don't do much better (and *plenty* of people have threads in this forum that the USB stick keeps allegedly corrupting data according to ZFS, yet the thumbdrive is just fine). This is why I preemptively wrote https://forums.freenas.org/index.ph...mendations-read-this-first.23069/#post-184183 that specifically mentions SATA DOMs. This was before 9.3 came out, because I already knew this was coming.

Today we are talk about card that are big and support good number of write. All esx system run perfect on sdcard so the question about work with freenas is relative to numbers of write.

Do you think I've somehow forgotten that everything in computers is always faster and bigger tomorrow? As I said above, not the problem... at all. If faster and bigger was the solution I'd be telling people to buy "Class ABC or faster or XYZ GB or larger". But I'm not. And the manual doesn't mention that because it doesn't apply.

If a card work in a phone for 1 year, can work in a system with few write, but sure we need someone that can tell how much freenas write to boot partition (sure apart update).

No, we don't. We didn't a year ago, and we won't next week. It's not the problem. In fact, when I was having my problems we were all still on 9.2.1.x. 9.3 has only made things worse because ZFS is used on the boot device and its writeable (the boot partition was read-only, so it was 100% obvious you wouldn't be doing many writes).

But, if you really want to know how may writes are done to your system drive, there are ways to track it. For comparison, my system has written less than 50MB to my USB stick since I updated the system on April 16th. But again, that's not the problem.

See, my choice of words with my original post was chosen carefully. I didn't say you would kill the SD card. I said you would kill the boot device's file system, which is exactly what will happen.

But hey, you're the one with the problem. I'm just some guy with 17k posts. ;)

 

[m4rv1n]

Do you think that I've somehow overlooked this very basic concept?

It doesn't matter how much FreeNAS writes and what file. That is not the problem at all. The problem is that SD cards, as a technology, cannot handle random read and/or random write workloads. ZFS hPERIOD. The technology was not designed to handle that workload properly. Even real bonafide USB sticks don't do much better (and *plenty* of people have threads in this forum that the USB stick keeps allegedly corrupting data according to ZFS, yet the thumbdrive is just fine). This is why I preemptively wrote https://forums.freenas.org/index.ph...mendations-read-this-first.23069/#post-184183 that specifically mentions SATA DOMs. This was before 9.3 came out, because I already knew this was coming.

If you have free sata port, sure this is better, but if you use SD, maybe is because you don't have free port. Anyway you have to consider that SSD are affected by same problem with random write, so this is not the solution is we talk about technology.

Do you think I've somehow forgotten that everything in computers is always faster and bigger tomorrow? As I said above, not the problem... at all. If faster and bigger was the solution I'd be telling people to buy "Class ABC or faster or XYZ GB or larger". But I'm not. And the manual doesn't mention that because it doesn't apply.

No, we don't. We didn't a year ago, and we won't next week. It's not the problem. In fact, when I was having my problems we were all still on 9.2.1.x. 9.3 has only made things worse because ZFS is used on the boot device and its writeable (the boot partition was read-only, so it was 100% obvious you wouldn't be doing many writes).

But, if you really want to know how may writes are done to your system drive, there are ways to track it. For comparison, my system has written less than 50MB to my USB stick since I updated the system on April 16th. But again, that's not the problem.

No, bigger is only because the time need to kill a big size ssd/sdcard with random write is longer that for a small size.
If you maintain boot device read only and you wrote 50MB (wrote, not occupied space) from April, how this can be a problem for the SDcard and for boot device's file system? You can't damage or kill if you not write to it, so the filesystem type is not relevant. Not?

See, my choice of words with my original post was chosen carefully. I didn't say you would kill the SD card. I said you would kill the boot device's file system, which is exactly what will happen.

But hey, you're the one with the problem. I'm just some guy with 17k posts. ;)

Can you explain more and technical what do you mean with "I didn't say you would kill the SD card. I said you would kill the boot device's file system" ?
If the filesystem was RW I understand that a big number of random IO go for damage SDcard or SSD, but we are still talking of read only filesystem, this is because I ask how do you write and how you can damage if you don't write.
Finally, I thank you for your answer, but remember that this is not a race for who have more post, a forum is to discuss and help, I think you know ;)

 

[Ericloewe]

If you have free sata port, sure this is better, but if you use SD, maybe is because you don't have free port. Anyway you have to consider that SSD are affected by same problem with random write, so this is not the solution is we talk about technology.



No, bigger is only because the time need to kill a big size ssd/sdcard with random write is longer that for a small size.
If you maintain boot device read only and you wrote 50MB (wrote, not occupied space) from April, how this can be a problem for the SDcard and for boot device's file system? You can't damage or kill if you not write to it, so the filesystem type is not relevant. Not?



Can you explain more and technical what do you mean with "I didn't say you would kill the SD card. I said you would kill the boot device's file system" ?
If the filesystem was RW I understand that a big number of random IO go for damage SDcard or SSD, but we are still talking of read only filesystem, this is because I ask how do you write and how you can damage if you don't write.
Finally, I thank you for your answer, but remember that this is not a race for who have more post, a forum is to discuss and help, I think you know ;)

SSDs are most certainly not affected, as they're not hampered by dubious controllers.

People have had luck with good USB drives, so a spare SATA port is not an absolute necessity. That doesn't mean it's reasonable to insist on trying to use stuff that has been known not to work (like SD cards).