I am running a RHEL 7.2 server and connecting to it by xrdp (using windows remote desktop). Is there a way to connect to the server and view it using both of my monitors? I've tried selecting the "use all my monitors for the remote session" box in Windows Remote Desktop Connection but that didn't make any difference.
I have (sort of) done this on Ubuntu. I don't know if it works for RHEL 7.2. I mostly got my info from here if you want more detail.
Edit the file here:
/etc/xrdp/xrdp.ini
Make an entry at the end of the file that looks like this:
[xrdp8]
name=Share-Screens
lib=libvnc.so
username=ask
password=ask
ip=127.0.0.1
port=ask
When the person you want to share screens with logs in, make note of the port shown in the connection log when they first log in. There will be two ports, make sure it is the second one. When you log in, change the module to "Share-Screens" and enter in the username and password to what the other person used and enter in that port that you took note of.
This works for me, but unfortunately I cannot share screens with a person remotely logged in and with me locally logged in. I hope this might help you, but this post is getting pretty old!
Related
I am a developer of ROS projects. Recently I am trying using ROS(melodic) on WSL2(Windows Subsystem for Linux), and all things works just great. But I got some trouble when I want to use another PC which also in the same local area network(LAN) to communicate with. Before setting the environment variables like "ROS_MASTER_URI, ROS_IP", I know that since WSL 2 work on Hyper-V so the IP show on WSL2 is not the one in the real LAN. I have to do some command like below in order to make everyone in LAN communicate with the specific host:PORT on WSL2.
netsh interface portproxy delete v4tov4 listenport=$port listenaddress=$addr
But here comes a new question:
The nodes which use TCPROS to communicate with each other have a random PORT every time I launch the file.
How can I handle this kind of problem?
Or is there any information on the internet that I can have a look?
Thank you.
The root problem is described in WSL issue #4150. To quote from that thread,
WSL 2 seems to NAT it's virtual network, instead of making it bridged
to the host NIC.
Option 1 - Port forwarding script on login
Note: From #kraego's comment (and the edited question, which I'm just seeing based on the comment), this is probably not a good option for ROS, since the port numbers are randomly assigned. This makes port forwarding something that would have to be dynamically done.
There are a number of workarounds described in that issue, for which you've already figured out the first part (the port forwarding). The primary technique seems to be to create a PowerShell script to detect the IP address and create the port forwarding rules that runs upon Windows login. This particular comment near the top of the thread seems to be the canonical go-to answer, although many people have posted their tweaks or alternatives throughout the very long thread.
One downside - I believe the script that is mentioned there needs to be run at logon since the WSL subsystem seems to only want to run when a user is logged in. I've found that attempting to run a WSL service or instance through Windows OpenSSH results in that instance/service shutting down soon after the SSH session is closed, unless the user is already logged into Windows with a WSL instance opened.
Option 2 - WSL1
I would also propose that, assuming it fits your workflow and if the ROS works on it (it may not, given the device access you need, but not sure), you can simply use WSL1 instead of WSL2 to avoid this. You can try this out by:
Backing up your existing distro (from PowerShell or cmd, use wsl --export <DistroName> <FileName>
Import the backup into a new WSL1 instance with wsl --import <NewDistroName> <InstallLocation> <FileNameOfBackup> --version 1
It's possible to simply change versions in place, but I tend to like to have a backup anyway before doing it, and as long as you are backing up, you may as well leave the original in place.
I have been working on my R studio session hosted by a Linux server and recently, ran a piece of code that was taking way too long to execute and I decided to kill it.
Here is the sequence of steps that I took - none of them helped me restore the health of my session.
1) Hit the stop button on R studio and be patient.
2) Ssh into my Linux server and ran the following command to kill all the processes running with my userid
killall -u myuserid
3) Removed the.RData,.Renviron,.Rhistory files from my workspace.
4) Ran the following R command via the Linux server for garbage collection
gc(reset=TRUE)
4) Restarted the entire Linux server.
I am running out of ideas and would really appreciate any other suggestions before I take more drastic steps like revoking access and granting it again(not sure if that would be the right fix)
Note: The browser window freezes every time I login, and it happens only for my R studio session, the rest of the users in the same network have no issues.
I solved this problem - Rstudio-serverfreezing. I think it was a network problem since I couldn't receive any response from calling "~~~~~~.cache.js". In this case, you can find out "~~~~~~~~~.cache.js" no response with pushing key before you click log-in button.
Anyway, here is my way.
Reset your Network with following orders
you can insert these into cmd terminal as an admin mode.
netsh winsock reset
netsh int ip reset
Reboot
The IP information may be erased. So if you're using fixed IP address, fill the blanks with as-is IP address.
That's all.
You may follow this way to recover the connection.
Our home network consists of two laptops, two tablets, two mobile phones, a printer and a NAS for backups. All running off a wireless router that provides the IP addresses.
Suddenly, about three days ago, I can no longer connect to the NAS. The message I get says "Error code: 0x80070035 The network path was not found." This happens on my laptop only; my wife's laptop doesn't have a problem. I've also checked and the printer works from my laptop.
The probable cause (but unproven) was when I made some changes to protect me from the Wannacry ransomware. I received messages from both Malwarebytes and Avast telling me to do the same thing. That was to go into the advanced settings of Windows Firewall and add two inbound rules. I don't remember the exact details but one rule affected TCP and one affected UDP (I'm somewhat out of my depth here.)
It was after this that I first saw the problem, so first I disabled the rules and then deleted them, but that made no difference. I've tried switching off Windows Firewall but that makes no difference either. I've researched the problem via Google and found some advice to reset TCP/IP settings. I did that via the command prompt, but that didn't work either.
Any other suggestions that don't involve a hard re-install or throwing the whole damn thing out the window?
"error code 0x80070035 network path was not found"
it can be on Windows Vista and Windows 7 Computers.
You can solve your problem like this:
"START" > "CONTROL PANEL" > "DEVICE MANAGER" > "NETWORK ADAPTERS"
Then click on "VIEW", and select "SHOW HIDDEN DEVICES".
In the expanded view you will see a long list of numbered "MICROSOFT 6to4 ADAPTER". Right click "DELETE" on all but 1 of them. When you have only 1 left, restart computer.
"error code 0x80070035 network path was not found"
I had the same error with several PCs in my network. I could not open shared folders of these PCs with the computer name. It was ok when I write the IP address.
Finally I just deselected TCP/IPv6 checkbox on the connection properties and its all ok.
Scenario:
Scenario:
In this part we have two System Administrators who administer a system which has
windows OS installed. First Admin is beside the system and second Admin is on
vacation. Both have username and password. In a negligence, second Admin left his
notebook containing login information and Server IP in a CafeNet. An intruder from a
black hat hackers group found it and decided to go another unknown place to access
the server using telnet. But that takes 10 minutes to get there. Imagine you informed
right from beginning minute. Now help first Admin to configure the system in a way
that while receiving any telnet connection, it warns the intruder with a message and
let him know that we have already covered this security hole. But, if it was a request
of second Admin (he calls or chat you!), then we let him to go ahead with telnet
connection!
Note: For some reasons, we can not stop Telnet, or change password today!
Well from the command line there is no way to do that, but I guess that you could make an application that would be capable of doing so and apply that to the Telnet server. Telnet cannot specifically be commanded to warn an intruder, it can only run the commands that it was intended to do.
I can't display dialog over a network using apple-script. I can connect to the computer but can not display a dialog using apple-script. Could anyone suggest a script to make this work??????
Thanks
Tom
To display a dialog on a remote machine you have to first setup an AppleScript application that runs on that machine.
On the remote machine
on displayDialog(d)
tell application "AppleScript Runner"
display dialog d
end tell
end tell
Save the above script as an Application: name it DialogHelper and flag the Stay open checkbox when saving. You can save it on the Desktop or wherever you like. Then run the Application and let it stay open.
Then from the local machine you invoke that AppleScript application to display the dialog.
On the local machine
tell application "DialogHelper" of machine "eppc://toms-mac.local"
displayDialog("hello")
end tell
-
Note that "Remote Apple Events" must be enabled in the Sharing Preferences on the target (remote) machine to allow this to work.
Of course the name of the machine (toms-mac.local in the example) must match with the one you see when opening the same preferences.
I've just tried, and it works between two Macs running Mac OS X 10.7 and connected on a local network
Side note
Normally scripting events that require user interaction (as display dialog) are not allowed between two machines, and trying to fire them end in a -1713 error.
Wrapping display dialog in the tell application "AppleScript Runner" block is a workaround to that limitation.
See also:
http://wisevishvesh.wordpress.com/2010/10/14/applescript-execution-error-no-user-interaction-allowed-1713/