[SCRIPT] create-autorun.sh

[luopa]

Dear OneCD, Dear ktuimala, (and other contributors I might have overlooked)

Thank you so much for the effort to create this script!

It runs like a charm on my system and has proven to be just the final piece I needed to implement my setup.
Very much appreciated - cheers!

[OneCD]

Cheers mate.

[Dario989]

Hello, can someone help to run caddyfile with script on bootup inside /share/CACHEDEV1_DATA/.qpkg/Caddy2 with command ./caddy run

[OneCD]

Hello, can someone help to run caddyfile with script on bootup inside /share/CACHEDEV1_DATA/.qpkg/Caddy2 with command ./caddy run

Do you have an autorun.sh file?

[dolbyman]

goes together with this post I think

viewtopic.php?f=32&t=168648

Quick reference would have been helpful @Dario989

[Dario989]

I using this way

mount $(/sbin/hal_app --get_boot_pd port_id=0)6 /tmp/config
touch /tmp/config/autorun.sh
chmod +x /tmp/config/autorun.sh
$EDITOR /tmp/config/autorun.sh

And inside have

#!/bin/sh
cd /share/CACHEDEV1_DATA/.qpkg/Caddy2 && ./caddy run

But when qnap is starting cant start all programs just down in gui is notification station starting.. and never load all programs

[OneCD]

Important to note: QPKGs are usually not ready to run when autorun.sh is executing. So, running a command on an installed QPKG that hasn't been reintegrated yet will fail.

Suggest using RunLast instead.

[GV231]

It looks like autorun.sh is not enough to modify smb.conf since QTS version 5.0: "/etc/init.d/smb.sh restart" now regenerates /etc/smb.conf and kills any changes in it
Am I wrongly restarting smb?

[Dario989]

Important to note: QPKGs are usually not ready to run when autorun.sh is executing. So, running a command on an installed QPKG that hasn't been reintegrated yet will fail.

Suggest using RunLast instead.

Thanks, this is what i need

[BikeDude]

Ah, here we go. Use 'sudo' this way:

Code: Select all

curl -skL https://git.io/create-autorun | sudo bash

First thank you for all the work on the script (and other posts I have seen here on Q Forms)....

Second let me clearly stated my problem is 98% of my own making....

Through a series of steps that would take me far longer to convey, then their value to ANYONE I find myself stuck....

Let me explain where I am and a small part of how I got there.

I converted NAS B to ZFS from QTS (had autostart enabled on NAS B). I moved a set of drives that WERE ZFS from NAS A (also with autostart enabled) to the newly ZFS system.... Perhaps you already can see where I am heading... laugh

NAB is all set except that if I look at the autostart via hardware control panel on NAS B it shows nothing.... Scripts are present (and I have backups so no problem).... Removed autorun

Code: Select all

sudo rm -rf /share/ZFS1_DATA/.system/autorun

Then tried reinstalling, unfortunately the symlink is ALREADY present/leftover (has the OLD value from when the enclosure was QTS and volume was CACHEDEV1_DATA and not ZFS1_DATA as it should be now.

Code: Select all

[~] # curl -skL https://git.io/create-autorun | sudo bash
create-autorun.sh 230218

info: NAS model: TVS-872XT 
info: QuTS hero version: 5.0.1 #20230112 
info: default volume: /share/ZFS1_DATA 
info: autorun partition should be: /dev/sdi6 
done: mounted ext2 autorun partition: /dev/sdi6 -> /tmp/create-autorun.fhOf9h 
info: confirmed partition tag-file exists: uLinux.conf (we're in the right place) 
done: created autorun script processor: /share/ZFS1_DATA/.system/autorun/autorun.sh 
done: created script store: /share/ZFS1_DATA/.system/autorun/scripts 
skip: symlink from partition already exists and points to: /share/CACHEDEV1_DATA/.system/autorun/autorun.sh 
skip: autorun.sh is already enabled in OS 
done: unmounted ext2 autorun partition 
info: please place your startup scripts into: /share/ZFS1_DATA/.system/autorun/scripts 
info: your autorun.sh file is located at: /share/ZFS1_DATA/.system/autorun/autorun.sh 

I tried reading through your bash script to figure out where the symlink source was so I could unlink it myself to try to either manually link some way or at the least allow me to rerun the your bash script which would do it automatically.

So LONG story short any suggestion on how to "virginize" just my "autorun system" so I can rerun your script. Worked fine first time on a clean ZFS system (NAS A) so I have no reason to doubt it or your ability to run fine again. As it stand snow because of the sysmlink to nowhere I can't of course even make a change in the control pannel UI.



Thanks again to any help

After this it's onto the little hell that is vfs_fruit & thee ancient SAMBA implementation QNAP is still shipping by default.... But I digress lol

[OneCD]

First thank you for all the work on the script (and other posts I have seen here on Q Forms)....

Cheers mate.

So LONG story short any suggestion on how to "virginize" just my "autorun system" so I can rerun your script. Worked fine first time on a clean ZFS system (NAS A) so I have no reason to doubt it or your ability to run fine again. As it stand snow because of the sysmlink to nowhere I can't of course even make a change in the control pannel UI.

Ah, that's a scenario I hadn't considered. I should probably get the script to validate the symlink target.

Anyway, I've just now added a 'force' argument to create-autorun.sh that (if-specified), will overwrite the existing symlink instead of skipping it.

To use this argument, please run:

Code: Select all

curl -skL https://git.io/create-autorun | sudo bash -s -- force

Thanks for reporting this.

[BikeDude]

First thank you for all the work on the script (and other posts I have seen here on Q Forms)....

Cheers mate.

So LONG story short any suggestion on how to "virginize" just my "autorun system" so I can rerun your script. Worked fine first time on a clean ZFS system (NAS A) so I have no reason to doubt it or your ability to run fine again. As it stand snow because of the sysmlink to nowhere I can't of course even make a change in the control pannel UI.

Ah, that's a scenario I hadn't considered. I should probably get the script to validate the symlink target.

Anyway, I've just now added a 'force' argument to create-autorun.sh that (if-specified), will overwrite the existing symlink instead of skipping it.

To use this argument, please run:

Code: Select all

curl -skL https://git.io/create-autorun | sudo bash -s -- force

Thanks for reporting this.

Bingo!

Thanks again. NP about not catching as it was clearly a corner case.

Since I have you on this thread one other quick question that COULD be related to my "converted" system here. Seems I also have an issue with my Entware install (one this system was installed by sherpa). My path is missing entware (opt..). Rather than playing wack-a-mole with QNAP’s .profile any way to use sherpa to re-run the path config? Looked at entware.sh and see the sherpa lines inside it... I tried stoping and starting the QPKG which I thought should force the regeneration of the path. Do I need to source it as well? I promise no more unrelated questions

Code: Select all

[/share/ZFS1_DATA/.system/autorun/scripts] # cat /opt/Entware.sh           
#!/bin/sh
# standard installation

RETVAL=0
QPKG_NAME="Entware"

_exit()
{
    /bin/echo -e "Error: $*"
    /bin/echo
    exit 1
}

QPKG_DIR=$(/sbin/getcfg Entware Install_Path -f /etc/config/qpkg.conf)

case "$1" in
  start)
  if [ `/sbin/getcfg ${QPKG_NAME} Enable -u -d FALSE -f /etc/config/qpkg.conf` = UNKNOWN ]; then
  	/sbin/setcfg ${QPKG_NAME} Enable TRUE -f /etc/config/qpkg.conf
  elif [ `/sbin/getcfg ${QPKG_NAME} Enable -u -d FALSE -f /etc/config/qpkg.conf` != TRUE ]; then
  	_exit  "${QPKG_NAME} is disabled."
  fi

  /bin/echo "Enable Entware/opkg"
	# sym-link $QPKG_DIR to /opt

	# the following line was inserted by sherpa: https://git.io/sherpa
	opt_path="/opt"; opt_backup_path="/opt.orig"; [[ -d "$opt_path" && ! -L "$opt_path" && ! -e "$opt_backup_path" ]] && mv "$opt_path" "$opt_backup_path"

	/bin/rm -rf /opt
	/bin/ln -sf $QPKG_DIR /opt

	# the following line was inserted by sherpa: https://git.io/sherpa
	[[ -L "$opt_path" && -d "$opt_backup_path" ]] && cp "$opt_backup_path"/* --target-directory "$opt_path" && rm -r "$opt_backup_path"

	# adding opkg apps into system path ...
	/bin/cat /root/.profile | /bin/grep "source /opt/etc/profile" 1>>/dev/null 2>>/dev/null
	[ $? -ne 0 ] && /bin/echo "source /opt/etc/profile" >> /root/.profile
	# startup Entware services
	/opt/etc/init.d/rc.unslung start
    ;;
  stop)
  	/bin/echo "Disable Entware/opkg"
	/opt/etc/init.d/rc.unslung stop
	/bin/sed -i '/source \/opt\/etc\/profile/d' /root/.profile
	/bin/sync
	/bin/sleep 1
	;;
  restart)
	$0 stop
	$0 start
	;;
  *)
	echo "Usage: $0 {start|stop|restart}"
	exit 1
esac

exit $RETVAL

[OneCD]

My path is missing entware (opt..). Rather than playing wack-a-mole with QNAP’s .profile any way to use sherpa to re-run the path config? Looked at entware.sh and see the sherpa lines inside it... I tried stoping and starting the QPKG which I thought should force the regeneration of the path. Do I need to source it as well? I promise no more unrelated questions

No worries mate.

The lack of a modified $PATH when using regular user accounts to access the NAS via SSH is a bit of a problem (not for sherpa though, it manually adds the Entware paths to its runtime environment). The only solution I've seen so-far is the user must manually modify their .profile to either include the Entware paths, or else source the Entware environment script. i.e. in your account $HOME, ensure .profile has a line that says:

Code: Select all

source /opt/etc/profile

This is a boot-persistent change.

This shouldn't be required for those who SSH-in as the 'admin' user. If it's not working, please check the contents of .profile in /root and ensure there's a source line as shown above.

[BikeDude]

Aussie or someone one with similar views?

Clearly losing my mind here as things are indeed ALL good now.... When I have had a bit more sleep I am going to think about if my failed autorun could have effected the path though I don't see how that could be the case since no path'ing in there. Going to chalk it up to sleep (and possible downstream consequence of playing games with /etc/machine-id, topic for another time and space)...

Code: Select all

/root
[~] # ls -la
total 36
drwxr-xr-x  3 admin administrators  280 2023-03-19 07:24 ./
drwxr-xr-x 26 admin administrators  680 2023-03-19 07:26 ../
-rw-r--r--  1 admin administrators  954 2023-03-19 08:56 .bash_history
-rw-r--r--  1 admin administrators  175 2004-10-08 19:49 .bash_logout
-rw-r--r--  1 admin administrators  161 2004-10-08 19:49 .bash_profile
-rw-r--r--  1 admin administrators 1687 2007-07-18 03:24 .bashrc
lrwxrwxrwx  1 admin administrators    6 2023-03-19 00:17 .BitTornado -> ../tmp/
-rw-r--r--  1 admin administrators   36 2023-03-19 07:23 .buzzer_warnning.conf
drwxrwxrwx  2 admin administrators  100 2023-03-19 07:24 .docker/
-rw-r--r--  1 admin administrators 6526 2007-07-11 02:35 index_default.html
-rw-r--r--  1 admin administrators   51 2023-03-19 07:26 .profile
-rw-rw-rw-  1 admin administrators    0 2023-03-19 07:24 .screenrc
lrwxrwxrwx  1 admin administrators   15 2023-03-19 07:23 .ssh -> /etc/config/ssh/
-rw-r--r--  1 admin administrators  923 2023-03-19 07:19 .vimrc
[~] # cat .profile 
export PS1='[\w] # '
reset
source /opt/etc/profile
[~] # 

So since it looked right.... on a lark I looked at the path and sure enough it's correct?!....

Code: Select all

[~] # echo $PATH
/opt/bin:/opt/sbin:/share/ZFS530_DATA/.qpkg/container-station/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin/X11:/usr/local/sbin:/usr/local/bin:/usr/local/jre/bin
[~] # 

Yes many years ago I remember installing Entware on another system and making the changes directly to the QNAP file and then writing them back to flash... So this time I thought I would take the easy way out and install it via sherpa since I was able to check that you were picking up the same "current" version of entware. One observation and suggestion if I might proffer... I think you are copying from your own repo (which I think came from the new MyQNAP?). For obvious reasons I try to source ANYTHING I install on any type of machine as close as possible to the canonical source (reliability of updates, validity of code, etc), in short just good practice- or should be. So when choosing to install entware via sherpa took me a bit to figure out where your package seems to be the same as the last packaged (qpkg) version of entware. My suggestion is perhaps on the wiki page you have for Sherpa you explain your rep sourcing and if at all possible just wrap the canonical repo... Theoretically it should mean less effort for you long term as you don't have too track upstream changes (though of course being downstream in an automated process, you are at their mercy if they make a breaking change). Again all of this is assuming my cursory review of how your script works, and I like to try to understand the tools I use rather then just blindly deploy (at least after the immediate crisis is over). Most people likely are not half as paranoid, or as anally retentive as me but amounts other jobs I did work as a security engineer so my paranoia bit is always flipped If you wish to continue this discussion perhaps we can find somewhere more appropriate? I know PM is off here, and not sure if you want to pick this up on the Sherpa thread or more directly? Can probably get you email out of GitHub (or you mine should you wish), just don't want to intrude without invitation.

Thanks again for all the patience. With sleep and a bit less stress I am usually a bit better then this (I hope) having been amongst other things a long time developer, network engineer, networking product manager and storage engineer product manager (20+ years) so clearly should know better but still learning a new/old thing or two since my time at the old "fruit" company....

All the best! (and apologies for the off topic post)
--T

Now back to figuring out what the NAS is now spontaneously rebooting (and adding to my madness)...

[OneCD]

Aussie or someone one with similar views?

Yup, I'm in SEQ.

Clearly losing my mind here as things are indeed ALL good now....

Sometimes, all it takes is a logout and login again.

One observation and suggestion if I might proffer... I think you are copying from your own repo (which I think came from the new MyQNAP?).

I use GitHub as a poor-man's CDN.

All external QPKGs (Entware, Par2, QDK) are copied from their original source and are unmodified. Entware (as you've already seen) gets some slight mods after install to help it play nice with other QPKGs that also use /opt.

My suggestion is perhaps on the wiki page you have for Sherpa you explain your rep sourcing ...

Good idea, it's on my todo list.

... and if at all possible just wrap the canonical repo... Theoretically it should mean less effort for you long term as you don't have too track upstream changes (though of course being downstream in an automated process, you are at their mercy if they make a breaking change).

I agree. I started including these external packages in sherpa so I could ensure they could be downloaded. Back in the early days of this project, QPKGs like Par2 and Entware were not reliably available (they were hosted on the QnapClub repo, which has a lot of downtime). Having another copy of them accessible to sherpa also meant I could calc checksums in-advance and ensure the validity of QPKGs downloaded to the end-user's NAS.

But, maybe it's time to rethink this. I really should be pointing sherpa to the original source where-possible. This should be achievable for Entware and QDK. I'll work on it.

Most people likely are not half as paranoid, or as anally retentive as me but amounts other jobs I did work as a security engineer so my paranoia bit is always flipped

No probs, I concur with your thinking, and I appreciate the examination by a security geek. Security is not my forte, so I've a lot to learn.

Cheers!