ken-ji
-
Posts
1,245 -
Joined
-
Last visited
-
Days Won
4
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by ken-ji
-
-
Check your system clock if its correct, and make sure its date is not in the past
-
hmm. redoing the keys is not a real solution.
I can only guess something happened on your backup server ssh files to change it.
but do this
main+~# cat /boot/config/ssh/known_hosts | grep bakup_ip backup_ip ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBGiAoa1bxGekGXAP+HA8pzHZ0qerF5Cy2KHuZdQF43zE02m9Op0BylDzrGiq0iek5AvpyUetp6yrmHJGSJNGfzw= backup:~# cat /boot/config/ssh/ssh_host_ecdsa_key.pub ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBGiAoa1bxGekGXAP+HA8pzHZ0qerF5Cy2KHuZdQF43zE02m9Op0BylDzrGiq0iek5AvpyUetp6yrmHJGSJNGfzw= root`backupif they don't match at any time, something changed on your USB
and you can check on the running system as well
main:/root/.ssh/known_hosts and backup:/etc/ssh/ssh_host_ecdsa_key.pub
Not a super paranoid guy, but if the Remote host id changed, i would not have recreated the keys right away and done some investigation, because the remote host id doesn't change unless some files are dropped from the backup USB for some reason. or someone gets in does something. maybe check if the time stamps of the ssh_host_*_key files are correct/expected vs when you upgraded and the other files in that directory.
Finally... not all your go lines are needed...
you either don't need the pub file on the backup, or you use the pub file to create the authorized_keys file like Hoopster's
-
On 3/13/2020 at 6:10 PM, mizifih said:
Let's say I set up a VLAN. It'll be like I have two sets of IPs range (hope that's the term) pm that port, right?
Will unRaid show it on the Routing Tables? Do I need to add something there? What do I do on unRaid once all this is set on my router?
And I need to set a fixed IP for unRaid, it has to keep its current IP, everything has, except that VM that must be apart from everything else.
yes, If you look at Unraid network settings, a VLAN will create a sub-interface which will look like another network interface that can only see all the VLAN-marked traffic. so Unraid will definitely show this on the routing table. It will be the job of the router that understand VLANs to route between them, Nothing changes for Unraid.
In actuality, a VLAN is just network packets with an extra label. if the device is VLAN aware, it see the extra label and process accordingly (member or not, etc) a non-VLAN aware device will not understand and either throw it out (as the case with PCs, and other clients) or just pass it on as it seems with most dumb/simple switches. This allows the VLAN to have its own subnet addresses/etc, and they can happily coexist with the main LAN traffic.
-
It's probably doable... just not an expert nor a fan of using a VM as a router on the same system as the clients
-
Like I said docker can't have two networks with the same subnet (ip range)
Your best bet is to alter your network such that both ISPs gateways have a different subnet ie 10.0.0.1/24 for ISP1 and 10.0.1.1/24 for ISP2, then use a multi-wan capable router or VM (don't like this option) to merge the two and do balance/failover/source routing/etc. and the pfsense VM is ok, idea but you need more network card ports on your Unraid than you have (I think)
-
Does your router support VLANs? if so, you can setup a VLAN, assign it to a port and plug Unraid eth1 to that. Make sure eth1 is not part of br0 though. Then just connect the VM to eth1(br1). Don't bother asigning an IP to eth1. Finally firewall off the VLAN from accessing the rest of the LAN and vice versa at the router.
Other option: get a cheap router. plug it into the main router. make sure they don't have the same subnet address. plug unraid eth1 to the 2nd router. (same as above make sure that eth1 is not part of br0, etc.) This will create a double NAT situation (like CGNAT for ISPs), which will prevent the LAN from accessing the VM, but the VM can access the LAN and the internet. But this will break stuff like dynamic port forwarding. and nothing on the internet can ever directly raech stuff on the VM. To port forward, you would need to manually configure router1 and router2.
-
Docker networks don't support networks with more than one gateway.
They also don't support having more than one docker network with the same subnet / gateway
What you really should have here is a router (even a linux VM) that will do src based policy routing against the two wans so ip group 1 uses ISP1 and other IPs use ISP2 but they all point to the router.
-
Using 2.7,
Tried running the benchmarks again, but only got one benchmark run and its still assigned to all the drives.
Looking inside the container appdata
root@MediaStore:/mnt/disks/SSD/appdata/DiskSpeed/Instances/local/driveinfo# tree hdwn180_gx2m_* hdwn180_gx2m_3942k0gjfavg_8tb ├── SMARTDescList.txt ├── benchmark │ ├── 1583361860341 │ │ ├── 0000000000000000.txt │ │ ├── 0000800155238400.txt │ │ ├── 0001600311787520.txt │ │ ├── 0002400468336640.txt │ │ ├── 0003200624885760.txt │ │ ├── 0004000781434880.txt │ │ ├── 0004800936673280.txt │ │ ├── 0005601093222400.txt │ │ ├── 0006401249771520.txt │ │ ├── 0007201406320640.txt │ │ ├── 8001563222016.txt │ │ ├── DriveLatency.sh │ │ ├── DriveLatency.txt │ │ ├── RandomSeek.sh │ │ ├── RandomSeek.txt │ │ ├── SequentialSeek.sh │ │ ├── SequentialSeek.txt │ │ ├── datestamp.txt │ │ ├── latency.txt │ │ ├── speed.json │ │ ├── valid.txt │ │ └── version.txt │ ├── 1583377616913 │ │ ├── 0000000000000000.txt │ │ ├── 0000800155238400.txt │ │ ├── 0001600311787520.txt │ │ ├── 0002400468336640.txt │ │ ├── 0003200624885760.txt │ │ ├── 0004000781434880.txt │ │ ├── 0004800936673280.txt │ │ ├── 0005601093222400.txt │ │ ├── 0006401249771520.txt │ │ ├── 0007201406320640.txt │ │ ├── 8001563222016.txt │ │ ├── DriveLatency.sh │ │ ├── DriveLatency.txt │ │ ├── RandomSeek.sh │ │ ├── RandomSeek.txt │ │ ├── SequentialSeek.sh │ │ ├── SequentialSeek.txt │ │ ├── datestamp.txt │ │ ├── latency.txt │ │ ├── speed.json │ │ ├── valid.txt │ │ └── version.txt │ ├── 1583378375557 │ │ ├── 0000000000000000.txt │ │ ├── 0000800155238400.txt │ │ ├── 0001600311787520.txt │ │ ├── 0002400468336640.txt │ │ ├── 0003200624885760.txt │ │ ├── 0004000781434880.txt │ │ ├── 0004800936673280.txt │ │ ├── 0005601093222400.txt │ │ ├── 0006401249771520.txt │ │ ├── 0007201406320640.txt │ │ ├── 8001563222016.txt │ │ ├── DriveLatency.sh │ │ ├── DriveLatency.txt │ │ ├── RandomSeek.sh │ │ ├── RandomSeek.txt │ │ ├── SequentialSeek.sh │ │ ├── SequentialSeek.txt │ │ ├── datestamp.txt │ │ ├── latency.txt │ │ ├── speed.json │ │ ├── valid.txt │ │ └── version.txt │ ├── 1583411489259 │ │ ├── 0000000000000000.txt │ │ ├── 0000800155238400.txt │ │ ├── 0001600311787520.txt │ │ ├── 0002400468336640.txt │ │ ├── 0003200624885760.txt │ │ ├── 0004000781434880.txt │ │ ├── 0004800936673280.txt │ │ ├── 0005601093222400.txt │ │ ├── 0006401249771520.txt │ │ ├── 0007201406320640.txt │ │ ├── 8001563222016.txt │ │ ├── DriveLatency.sh │ │ ├── DriveLatency.txt │ │ ├── RandomSeek.sh │ │ ├── RandomSeek.txt │ │ ├── SequentialSeek.sh │ │ ├── SequentialSeek.txt │ │ ├── datestamp.txt │ │ ├── latency.txt │ │ ├── speed.json │ │ ├── valid.txt │ │ └── version.txt │ ├── 1583412489111 │ │ ├── 0000000000000000.txt │ │ ├── 0000800155238400.txt │ │ ├── 0001600311787520.txt │ │ ├── 0002400468336640.txt │ │ ├── 0003200624885760.txt │ │ ├── 0004000781434880.txt │ │ ├── 0004800936673280.txt │ │ ├── 0005601093222400.txt │ │ ├── 0006401249771520.txt │ │ ├── 0007201406320640.txt │ │ ├── 8001563222016.txt │ │ ├── DriveLatency.sh │ │ ├── DriveLatency.txt │ │ ├── RandomSeek.sh │ │ ├── RandomSeek.txt │ │ ├── SequentialSeek.sh │ │ ├── SequentialSeek.txt │ │ ├── datestamp.txt │ │ ├── latency.txt │ │ ├── speed.json │ │ ├── valid.txt │ │ └── version.txt │ ├── 1584049865832 │ │ ├── 0000000000000000.txt │ │ ├── 0000800155238400.txt │ │ ├── 0001600311787520.txt │ │ ├── 0002400468336640.txt │ │ ├── 0003200624885760.txt │ │ ├── 0004000781434880.txt │ │ ├── 0004800936673280.txt │ │ ├── 0005601093222400.txt │ │ ├── 0006401249771520.txt │ │ ├── 0007201406320640.txt │ │ ├── 8001563222016.txt │ │ ├── DriveLatency.sh │ │ ├── DriveLatency.txt │ │ ├── RandomSeek.sh │ │ ├── RandomSeek.txt │ │ ├── SequentialSeek.sh │ │ ├── SequentialSeek.txt │ │ ├── datestamp.txt │ │ ├── latency.txt │ │ ├── nosubmit.txt │ │ ├── speed.json │ │ ├── valid.txt │ │ └── version.txt │ ├── BenchInfo.wddx │ ├── allspeed.json │ └── avgspeed.json ├── config.json ├── image.png └── smartreport.wddx hdwn180_gx2m_3992k0nqfavg_8tb ├── config.json └── image.png hdwn180_gx2m_399fk0g3favg_8tb ├── config.json └── image.png hdwn180_gx2m_79iuk0vufavg_8tb ├── config.json └── image.png 7 directories, 146 files
-
Any idea why my 4 Toshiba N300s get mapped together as far as benchmarks go?
My 4 Segate Archive Drives didn't get lumped together in the benchmarks
Each of the Seagate get their own benchmark speed graph
Each N300 gets all of the N300 benchmarks together in the graph (there's one extra because I got confused as to which one had been benched)
-
46 minutes ago, markD182 said:
I already bought 2 idential USB's and intend on doing 1:1's of them periodically along with better off-unraid back-ups!
FYI: this won't help you in the primary USB dies, as you will still get the "The registered GUID does not match the USB Flash boot device GUID" error. However, you can then transfer the license to the new USB painlessly in the GUI. If you were to swap USBs after cloning it. you'd see what I mean.
You won't need identical USBs, as they can't be identical due to the GUID. so when you replace them again, you won't need to go through the trouble of getting identical ones ( and possibly mixing them up)
-
1
-
1
-
-
Click on the container icon and select >_ Console
This will open a terminal inside the container, then run the following commands first
su - nobody cd Dropboxthen you can run the dropbox.py command for the various commands to see the sync status
-
1
-
-
Sorry for not answering your PM, but the container does have the dropbox.py script which can be used to check the status of the sync
-
Hmm. I tried uploading filenames in with JPN characters, but I don't see the issue.
Logging in via terminal shows the filename correctly in UTF-8. attempting to LS without UTF8 in the LANG shows question marks instead of a proper filename.
I do see that winscp can be forced to assume that UTF-8 is enabled before you connect to the server in the advanced settings.
Maybe, your issue is that the filenames on you original files are not in UTF8 but in the native iso-1252 latin, and winscp copied the filenames as is, resulting in native latin filenames, which Samba assumes they are invalid UTF-8 filenames and hides them to avoid weird things from happening on the client side.
Other than this I have no idea what else can be done, other than trenaming the files to UTF-8, and making sure future SCP uploads have the UTF setting forced.
-
Upgraded to 6.8.3. Without issues so far. Though I need to test Docker + IPv6 behavior
-
8 hours ago, trurl said:
I power down the eSATA enclosure, but I don't have to stop the array to get this "hot swap" to work.
Never had a separate enclosure apart housing unassigned devices... interesting.
-
You should either post your diagnostics or at the least the docker settings page and your network interfaces
-
Hot swapping works, but obviously not with the array drives.
Unassigned Drives work well, but with a little caveat: Unraid doesn't do a scan of the drive ports unless the array is stopped. There's a linux command for forcing the scan to occur, but for most people, its best to do it with the array stopped.
The command in question varies depending on your actual hardware but its like:
echo "- - -" > /sys/class/scsi_host/host0/scanwhere the 0 must be replaced with correct controller card.
-
What language are your filenames in? I don:t have that issue with my files in Japanese.
And which direction is the transfer giving you issues?
-
Can you see docker1 in the drop down list of networks?
Can you see docker1 in the list of docker networks under Settings | Docker ?Please the read both threads thoroughly. There are gotchas like not being allowed to have more than one docker network with the same gateway address.
-
I turned IPv6 on on all pertinent interfaces just as I updated to 6.8.3 - and I don:t see any adverse effect, other than Unraid trying to assign it self a bunch of IPv6 addresses. I:ll see what happens if they are disabled at a later date. However, the Docker extra params I:m using is still ok for my needs as the container still gets a class one IPv6 address that participates on the LAN without interference from Docker (or network config for that matter)
-
6.8? or 6.9?
-
hmm. have the same network setup as @Kaldek
But I use a secondary NIC and configure it for no IP4 assigned. no IPv6 assigned either. (Turned on IPv6 but did not assign one) - the Containers VLAN
and only IPv4 on the docker networks
Then I add this to all my containers
<ExtraParams>--sysctl net.ipv6.conf.all.disable_ipv6=0 --sysctl net.ipv6.conf.eth0.use_tempaddr=2</ExtraParams>
This then makes them have get SLAAC IPV6 addresses (disabling the privacy extension - temporary IPv6 address)
I suppose I can make them better but havent had time to tweak the network stack as I'm doing all this remotely.
EDIT just realized it might not even be necessary to enable IPv6 on this secondary NIC as the base eth1 is IPv4 only but a container there does get IPv6 address anyway
-
@Eddyall@witalit
@1812 is referring to the relatively cheap Mikrotik 10G switch https://mikrotik.com/product/crs305_1g_4s_in. Not the routers which may present a steep learning curve if you are a network newbie.
Though this can work as a router too... -
This is what @johnnie.black means by x8 link:
My setup is basically the HBA (LSI 9206-16e) connected to a Areca 4036 (8x enclosure) enclosure via dual SFF 8644 cables.
I guess have more bandwidth available than I have drives...
Bridge container to VLAN instead of using a different IP on the VLAN
in Docker Engine
Posted
Disclaimer: My VLANs are isolated and only the router bridges them. I don't give Unraid additional IPs to muck up accesses. (this is a side effect of the older network setting where assigning the container to the same interface as the host and giving its own IP isolates them)
Have you tired to access the container while its connected to the regular bridged network same as the untagged VLAN, yet using the VLAN30 IP?
I mean while the VM is reachable via 192.168.1.10:2345, try reaching it via 192.168.30.10:2345 as well.
I distinctly remember docker actually running a proxy that bind on all the IP addresses on the host then forwarding the connections to the container in the internal docker bridge.