logic: if the kill switch is off, when no physical input events happens, or not focused on scrcpy window with keyboard/mouse input events on pc for some time, allow to interact with the phone.
get physical events:
warning: this command could be offline for a short period of time after using the scrcpy. must automatically reconnect if the device is not offline.
1 2
adb -s 192.168.10.3:5555 shell getevent
to get focused window title:
hint: for headless ssh sessions, must set apropriate xorg environment variables, eg: env XAUTHORITY="/run/user/0/gdm/Xauthority" DISPLAY=:1 python3
general method:
1 2 3
import pywinctl pywinctl.getActiveWindowTitle()
for linux:
1 2
watch -n 2 xdotool getactivewindow getwindowname
for macos: (allow permission first, deprecated since it will not get the window title instead of the program name)
sleep 3 && osascript -e 'tell application "System Events"' -e 'set frontApp to name of first application process whose frontmost is true' -e 'end tell'
when kali is off, this mac will go crazy and hang everything.
need to scan for kali existance on demand, not all the time.
developing
should we use p2p networks to speed up remote connections like n2n or tinc?
would it be interesting to run all our kali connectors ranged from vscode-ssh-connect, rclone mount and direct ssh connection via kali command dynamically by our kali discovery service, if we can reload the nginx daemon on demand.
using redis to store some daemon reported values.
how about we set the workding directory of redis-server to /tmp so that the dump.rdb file will never take space after reboot?
we need to know if this will successifully launch after reboot since /tmp may not exist by that time
if you install p2p server nodes on primary server (with hard-to-crack password and proper configs (no brute-forcing)?) you might want to add that (n2n) server node at home.
use n2n to send udp packages among clients, try to create direct link between devices which will speed up ssh connection speed. supernode creation could be used along with frpc
somehow brew does not have n2n as a package. macports has it, which requires xcode (huge!) to be installed.
on macos, when crontab is created, cron will be automatically launched by launchd.
cronjobs may need to launch with the $(which env) prefix.
the problem of internet disconnetion will most not likely to interfere with the server since frpc has auto reconnection and the update hook is the filesystem watchdog, which will not run when no changes made (including the offline period)
the watchdog may be replaced by some mirror fuse system, which will report every access request to our dedicated server.
we have seen this behavior (filesystem mirroring) in our gitfuse code. but does that support symlink? should we really take care of that? or should we forget that and just use inotify instead?
maybe it will affect the client when mounting the remote filesystem using sshfs or rclone, but that has to be verified.
serve and mount remote filesystem
before serving, make sure the path /media/root/help/pyjom exists by running our mount script
before mounting, use rclone config to setup remote associated with a name. make sure the hostname is localhost instead of ip address to avoid certificate issues. do not install rclone from brew since it does not support fuse. instead, install from here
1 2
rclone mount webdav_local_nginx:/ /Volume/CaseSensitive/pyjom_remote_mountpoint --ca-cert /Users/jamesbrown/Desktop/works/host_discovery_ssh_local_connect/certificates/localhost.crt
after mounting, seems zsh on macos is not working very well with macfuse. bash works. does bash/fish works with sshfs as well? maybe that will save efforts.
encryption and invalid HTTPS certificates
use nginx to redirect remote server as localhost, since the host name on the certificate is localhost we cannot let chrome to trust anything other than that
currently we only have one, which uses direct ip address instead of a hijacked domain. maybe it is time to consider some faster server providers.
use a universal ssh as workspace extension called SSH FS
drawbacks of SSH FS extension
some drawbacks of this SSH FS plugin is that it cannot use the plugins from remote machine, also having issue whe jumping to remote files from terminal output. to run code-insider instead of code-oss, maybe we could spin up the official ssh connector, which can only be automated by publickey authentication.
syncing, updating and viewing using watchdog and sshfs(deprecated since it shares connection with vscode remote and maybe slower than rclone serve webdav?)
to make sure the changes are updated regularly, we need a filesystem watchdog on kali, which will trigger the action of syncing, utilizing inotify. shall that be adopted on macos? maybe. but my extra editors can be vim or nvim, so it is not so hard to predict. but if it can monitor the file read events, we don’t need those legacy editor program hooks.
at least we need to see the output, so we need to mount the remote filesystem as sshfs, then use ffplay to view it.
solution
for now, two viable ways:
one using code-server, the other using code-server-insider provided by code-insider. when using builtin code-server-insider, remember it will not share the plugins installed by code-insider. the remote executable location is at /root/.vscode-server-insiders/bin/12b08be500f8a307f30e92cbc3ee39ba115eab69/bin/code-server-insider or something. must set the local setting remote.SSH.useLocalServer to false.
when using code-server, one can connect to the workspace using browser, instead of vscode builtin remote connector.
remote or local address must at least have port number specified, optionally with host address like: [host]:<port>
-L opens a local port at local address and forward to remote address. -R opens a remote port at remote address and forward to local address. -N disable the tty connection. -v shows the debug info.
enable pubkey authentication for nomachine:
first generate the key with ssh-keygen, copy your pubkey content at .ssh/id_rsa.pub (local host) to remote host at ~/.nx/config/authorized.crt, one pubkey per line.
next change the setting AcceptedAuthenticationMethods as NX-private-key in file /usr/NX/etc/server.cfg at remote host.
no need to restart the service. change your connection method to key based authentication and select the private key file path.