As per the subject, is /boot/config/go still used?  I'm asking as I have stuff in my /boot/config/go file that never gets run.

 

Follow up question - If /boot/config/go is still used, why would the commands there get ignored?

 

Here is /boot/config/go, for reference:

 

#!/bin/bash
# Start the Management Utility
# modprobe i915
# chmod -R 777 /dev/dri

# copy SSH keys
mkdir -p /root/.ssh
chmod 700 /root/.ssh
cp /boot/config/ssh/authorized_keys /root/.ssh/
chmod 600 /root/.ssh/authorized_keys

mount -o remount,size=384m /var/log
/usr/local/sbin/emhttp &

 

I have verified that authorized_keys is not where it should be after reboot.

What version are you running?  And please attach your Diagnostics file    Tools    >>>    Diagnostics    to your next post!   There is information in that file should indicate what is going on. 

4 minutes ago, Frank1940 said:

What version are you running?  And please attach your Diagnostics file    Tools    >>>    Diagnostics    to your next post!   There is information in that file should indicate what is going on. 

I'm running 6.9.0-beta25.  No need for diagnostics yet since I just want to know if /boot/config/go is still used at this point.  If the answer is yes, I'll worry about it then (I'm not comfortable with attaching those diagnostics dumps to forum posts, for fairly obvious reasons).

6 minutes ago, digitalformula said:

If the answer is yes,

Yes

2 minutes ago, Frank1940 said:

Yes

Perfect, thank you.  (Seriously, thanks - not trying to be a smartass).

11 minutes ago, digitalformula said:

I'm not comfortable with attaching those diagnostics dumps to forum posts, for fairly obvious reasons

Not really obvious. Is there something specific not already anonymized in the diagnostics that you think needs to be anonymized?

Did you read the release notes for 6.9.0-beta25, specifically the section on ssh improvements?

 

it will have already created a symlink /root/.ssh -> /boot/config/ssh/root which will make your command in the go file to create /root/.ssh fail.

Edited July 28, 20205 yr by remotevisitor

3 minutes ago, trurl said:

Not really obvious. Is there something specific not already anonymized in the diagnostics that you think needs to be anonymized?

Some, yes.  Examples:

 

- There's a folder called "shares".  The share names within that folder are "anonymized" by having only the first and last letter included, but syslog.txt includes references to the full share name.  I have shares based on customer names that I don't want exposed.

- IP address info isn't anonymized i.e. my client IP addresses are in there

- VM names are in logs/libvirt.txt and I have VMs matching project names

- Hardware serial numbers are in syslog.txt e.g. HDD serials (this actually is a big deal for some client types)

- sshd port number is in syslog.txt

(etc)

 

I can understand the potential  argument that none of this is overly useful for malicious purposes if your network security is up to scratch, but that argument is negated by posting diagnostics on a forum.  That said, IMO system information must be either 100% anonymized (*all* instance-specific/identifiable data removed) or there's no point in anonymizing at all.  In my experience, logs can show why something happened without showing who it happened to.  The disclaimer is that yes, there are situations where information is useless without knowing who was involved, but that's not the case here (again, IMO).

 

15 minutes ago, remotevisitor said:

Did you read the release notes for 6.9.0-beta25, specifically the section on ssh improvements?

 

it will have already created a symlink /root/.ssh -> /boot/config/ssh/root which will make your command in the go file to create /root/.ssh fail.

Ok, good to know.  And no, I missed that info in the release notes - happy to accept fault for that.

 

However, I wouldn't expect that change to cause /boot/config/go to fail/stop executing at that point.  If that were the case I guess emhttp wouldn't start, either (and it does, since that's the webserver GUI, right?)

Read the section  of the syslog (   Tools   >>>   System Log     ) where the go file is being executed.  You can find it by search using this:   <space>go<space>  

 

Hopefully, the Bash shell will show any errors encountered in its execution.

 

13 hours ago, Frank1940 said:

Read the section  of the syslog (   Tools   >>>   System Log     ) where the go file is being executed.  You can find it by search using this:   <space>go<space>  

 

Hopefully, the Bash shell will show any errors encountered in its execution.

 

Unfortunately that doesn't reveal anything.  I could throw some debug stuff in there though, I guess.

 

Jul 27 10:59:16 ***-unRAID root: Starting go script
Jul 27 10:59:16 ***-unRAID root: Starting emhttpd