-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
network paths #4
Comments
Hey man! Thanks for reporting this back! :) Thinking of more inclusive solution. That makes sure the mount points are alive before running. I think solution would be something like below. The function works on Ubuntu and i expect it to work on all GNU hosts. This should also work in theory for the broken network directories. Any chance you can test this?
|
There is a bit to unpack so I will try to be as short as possible. Some test results Server(debian)- serves ssh and firewalls with DROP after ssh mount is established to simulate issue Clients - Ubuntu / CentOS 7 (same as client that reported issue) Ubuntu: CentOS: I have further tested my suggestion as well btw.. even though my target is /mnt/sshfs and I am pointing find to /mnt (to make life easier) it STILL has the same results as mountpoint or the find without the exclusions Back to the drawing board. |
Sounds like mountpoints is not the right tool for this. While we look into this, I will change the function to exclude the hashing of the mounted directories to remediate this issue for the time. What if we did not hash the files in the mounted dirs but we did a So something like
|
Updated the latest version to avoid network mounted directories while we work on this issue. Script will check for executables in
Using |
I was going to suggest
but neither works really.. as soon as the find of / goes into /mnt and lists the sshfs directory... caboom. dont get me wrong, when the firewall is off.. it will see it and IGNORE it.. but when the firewall is on and the traffic is DROPed.. seeing it makes it go boom. |
I will try to deploy a testing environment of my own and work on this issue over the weekend. For now though, the recent update I made to the public version of the function should resolve this issue with some feature reduction :/ Assigning this to myself. |
I've been trying to think of a way tbh but keep coming up empty on this one. Nevertheless the hang time as expressed by the client is not the same, CentOS takes considerably more time to get the input/output error due to the process being picked up as dead.. but in no way shape or form reaching "overnight" levels. |
Have you tried the recent version of the script? v1.3.2 should stop all hanging. I've made adjustments to avoid network drives for now. |
Yeah the The icing on this cake: |
Reverted back to v1.3.1 for now. I think we leave it as it for now as issue seems not replicable. |
Working on a case today and the script hang.. after a bit of investigation and we figured out it was the get_executables function which states:
find / -type f -perm -o+rx -print0 | xargs -0 sha1sum
The reason behind the hang was that the system had a network share (fuse.sshfs) that was mounted, yet the outgoing/incoming traffic due to the incident was moderated heavily.. so basically the mountpoint was broken.
To avoid that with any other situation similar we could do a quick fix of:
find / ! -fstype nfs,sshfs,fuse.sshfs -type f -perm -o+rx -print0 | xargs -0 sha1sum
Or I we could explore a more inclusive solution that makes sure the mount points are alive before running the find (or running it with parameters defining specific paths) if we really want ALL the bins from ALL the things
The text was updated successfully, but these errors were encountered: