P4 novice here !
I want to create a workspace and sync in dirs/files from a p4 repo. Simple stuff, which I can't get to work. What's wrong with this picture ?
The p4 server & port : myp4server.xyz.com:1712
The p4 repo is //etc/freeze_check
I create a dir (in linux) /home/me/freeze_check and cd into it.
I type "p4 client" and fill it in like this...
Client: my_client_name
Owner: me
Description:
Created by me.
Root: /home/me/freeze_check
Options: noallwrite noclobber nocompress unlocked nomodtime normdir
SubmitOptions: revertunchanged
LineEnd: local
View:
//etc/freeze_check/... //my_client_name/...
I left the "host" out but have this in /home/me/P4OCNFIG
P4PORT=myp4server.xyz.com:1712
P4CLIENT=my_client_name
I also "setenv P4CLIENT P4CLIENT" (I saw a working P4 workspace that did this)
Then I exit the editor. It says it saved the client.
Now, If I type "p4 client -o my_client_name", I see what I just defined.
If I type "p4 client -o" (no client name), it comes up with something different, the same thing that I started out with.
Q: How can I associate the client that I just created with the dir that I just created ?
Q: Is the P4CONFIG file necessary? Is the setenv P4CONFIG necessary?
Thanks for any help
No, you don't have to use P4CONFIG, but it can be convenient if you use multiple clients on the same workstation.
Try setenv P4CLIENT my_client_name
Related
I've been trying to get access to Windows Server 2019 without password through OpenSSH protocol.
So I've created new key which I need it to be copied to the Windows Server, I've tried this:
ssh-copy-id -i ~/.ssh/id_rsa user#server
But I get this after entering correct password:
'exec' is not recognized as an internal or external command,
operable program or batch file.
The system cannot find the path specified.
The system cannot find the path specified.
My issue is how to transfer key from one windows machine(using gitbash, WSL, powershell or whatever)
to Windows Server 2019 location of authorized keys if I am not mistaken.
I am desperate enough to do it manually but location of those keys is mystery to me, do I need to set something on Windows Server first so that it can accept keys for authentication ?
What is the alternative on ssh-copy-id from Windows machine to Windows Server 2019 ?
Found solution:
Followed this helpful youtube guide, props to the
https://www.youtube.com/watch?v=Cs3wBl_mMH0&ab_channel=IT%2FOpsTalk-Deprecated-SeeChannelDescription
Also, installing OpenSSHUtils worked with:
Install-Module -Name OpenSSHUtils -RequiredVersion 0.0.2.0 -Scope AllUsers
Also this guide helped:
https://www.cloudsma.com/2018/03/installing-powershell-modules-on/
My server didn't have access so I manually copied file from:
C:\Program Files\WindowsPowerShell\Modules to the server's:
Server:\Program Files\WindowsPowerShell\Modules
First, this error message is followed by microsoft/vscode-remote-release issue 25
Current workaround (the context is VSCode, but should apply also for regular SSH connection):
Also, for anyone else here that loves their bash on windows but still wants to be able to use VSCode remote, the workaround I have currently setup is to use an autorun.cmd deployed on the servers that detects when an SSH connection is coming in and has a terminal allocated:
#echo off
if defined SSH_CLIENT (
:: check if we've got a terminal hooked up; if not, don't run bash.exe
C:\cygwin\bin\bash.exe -c "if [ -t 1 ]; then exit 1; fi"
if errorlevel 1 (
C:\cygwin\bin\bash.exe --login
exit
)
)
This is known to work with Cygwin bash, unsure about bash that ships with windows; I imagine it's very sensitive to how the TTY code works internally.
This way, launching cmd.exe works normally, using VSCode (because it does not allocate a PTY) works normally, but SSH'ing into the machine launches bash.exe.
I suspect it would also work using the bash.exe which comes with Git for Windows, should it be installed on the target server.
The destination file should be on the server:
%USERPROFILE%\.ssh\authorized_keys
If you can do it manually, simply try and scp it instead of using ssh-copy-id
scp user#server:C:/Users/<user>/.ssh/authorized_key authorized_key
# manual and local edit to add the public key
scp authorized_key user#server:C:/Users/<user>/.ssh/authorized_key
(again, I would use the scp.exe coming with Git For Windows, installed this time locally)
Found solution:
Followed this helpful youtube guide, props to the
https://www.youtube.com/watch?v=Cs3wBl_mMH0&ab_channel=IT%2FOpsTalk-Deprecated-SeeChannelDescription
Also, installing OpenSSHUtils worked with:
Install-Module -Name OpenSSHUtils -RequiredVersion 0.0.2.0 -Scope AllUsers
Also this guide helped:
https://www.cloudsma.com/2018/03/installing-powershell-modules-on/
My server didn't have access so I manually copied file from:
C:\Program Files\WindowsPowerShell\Modules to the server's:
Server:\Program Files\WindowsPowerShell\Modules
I am getting this error on VS Code and have no clue why it fails
[15:14:59.543] Log Level: 2
[15:14:59.555] remote-ssh#0.51.0
[15:14:59.555] win32 x64
[15:14:59.560] SSH Resolver called for "ssh-remote+xx.xx.xx.xx", attempt 1
[15:14:59.561] SSH Resolver called for host: xx.xx.xx.xx
[15:14:59.561] Setting up SSH remote "xx.xx.xx.xx"
[15:14:59.621] Using commit id "0ba0ca52957102ca3527cf479571617f0de6ed50" and quality "stable" for server
[15:14:59.624] Install and start server if needed
[15:15:01.964] getPlatformForHost was canceled
[15:15:01.965] Resolver error: Connecting was canceled
[15:15:01.973] ------
Add one key in your settings.json as below. Please remember to replace the $remote_server_name to yours.
"remote.SSH.remotePlatform": {
"$remote_server_name": "linux"
}
Menu: File->Preference->Settings
Or click the icon to open settings.json:
In dialog box where you have typed user#host type/select Linux/Windows/etc. depends what you are using, then type/select Continue, then type password for remote session.
For those getting this error on Windows: Check if you have multiple ssh clients installed.
How I solved it was by adding my ssh-configuration to ALL ssh-config files.
In my case I had one in
C:\Users\USER_NAME.ssh\config (this is the one that the remote extension used to give me connection options)
and another in C:\Program Data\ssh\ssh-config
After adding my ssh-config setting to both I got the prompt to select virtual hosts' OS. Tried editing the settings.json file directly, but I think it gets confused because of the multiple ssh-configurations.
P.S.
Tested it for both private key and password enabled connections and it work with either.
I got a similar problem, but the error logs were bigger. Before that, I deleted the python and reinstalled it. Perhaps this led to the problem. Just reinstalled "Remote -SSH" extension in vscode and it worked for me.
In my case there were two files that look like
vscode-remote-lock.<user>.<xxx>
vscode-remote-lock.<user>.<xxx>.target
where was my remote user name and xxx the VS Code Remote Server build hash.
These two files on the remote server in the folder.
/run/user/1000/
I deleted both files and then VS Code came up right away. I have encountered this a few times now. VS Code Remote Server install is not very robust. I use it on about 7 remote machines and every once in a while something goes awry and it cannot recover from simple errors and gets stuck in installation loops.
This trick only works if there is a valid ~/.vscode-server on the remote machine with a hash that matches your local VS Code installation.
If you got here because you were trying to install VS Code in the first place and for whatever reason VS Code had issues with the remote installation, I highly recommend installing it manually by downloading and extracting the tar file to the remote machine directly.
I have tried playing with the setting "Use remote.SSH: Use Flock" and other tricks posted on StackOverflow but none of these work for me whenever I have remote installation issues. I cannot figure out why on some machines, a smooth remote installation is not possible. Even when all of my ssh keys and remote ids have been copied and tested from both the Windows command line and inside a WSL Ubuntu instance.
If VS Code Remote Server installation had slightly better error logic and better error messages none of us would be wasting hours doing this simple task.
I was getting the exact same error as the original poster received and yet none of the other answers were my issue.
I installed VS code on Penguin on an Acer Chromebook R11.
I followed the steps for Debian here : https://code.visualstudio.com/docs/setup/linux
It works like a charm but I need to connect to my remote dev server using the official extension RemoteSSH by Microsoft.
Then I configured a .ssh folder for the user with correct permissions : https://gist.github.com/grenade/6318301
Now I get :
Could not establish conntection to the "servername", the VS Code Server failled to start
The detailled log is :
[11:39:39.572] Resolver error: The VS Code Server failed to start
[11:39:39.609] TELEMETRY: {"eventName":"resolver","properties":{"outcome":"failure","reason":"ExitCode","askedPw":"0","askedPassphrase":"1","asked2fa":"0","askedHostKey":"0","gotUnrecognizedPrompt":"0","remoteInConfigFile":"1"},"measures":{"resolveAttempts":1,"exitCode":32,"retries":1}}
[11:39:39.620] ------
I don't have any idea of what it could be. Do you have one ?
I was having a similar issue and I resolved it by deleting the ".vscode-server" directory that was created on my server. It's a hidden directory that is created in the home directory (you can use "ls -la" to display all the files I believe). My hunch is that some incorrect data is being cached there so deleting the directory will give you a clean slate.
After deleting, you can try connecting again through remote-ssh on vscode.
I'm following the instructions found here.
When I try to run $ heroku pg:psql or $ heroku pg:psql HEROKU POSTGRESQL_BROWN I recieve the following error message:
! The local psql command could not be located ! For help
installing psql, see local-postgresql
I can't find anything useful on the link it gives me (it just links to the instructions I was already using, but further down the page) nor can I find this error anywhere else.
If I've missed anything you need to know to answer this, just let me know. I'm rather new to all this and teaching myself as I go.
I had same error even after installing Postgres locally.
But after seeing this
I saw that "pqsl" was not in the PATH so I then did
PATH=%PATH%;C:\Program Files\PostgreSQL\9.2\bin
which worked for me
I have since solved this myself. When I ran heroku pg:info it says the version number is 9.1.8, I was locally running 9.2
installing 9.1.8 and ensuring Path pointed to the appropriate folder solved the problem.
After you change the path, make sure to restart the terminal!
Set the PATH. To find out the PATH of your psql script (on mac) open the sql shell script from your finder in Applications/Postgres installation. This will give you a hint as to where it is installed. That opened a window which told me it is located here: /Library/PostgreSQL/8.4/scripts/runpsql.sh
Then, I set the PATH variable from the terminal window by typing:
$ PATH="/Library/PostgreSQL/8.4/bin:$PATH"
(depends on the location of your PostgreSQL installation, find your bin path first, another exp: /usr/local/Cellar/postgresql#9.6/9.6.8/bin)
OR.....
You can also connect to the shell by opening the shell directly from your postgres installation folder. Then enter the credentials. If you don't know the credentials, here is how to find them out:
$ heroku pg:info
=== HEROKU_POSTGRESQL_RED_URL (DATABASE_URL)
$ heroku pg:credentials HEROKU_POSTGRESQL_RED_URL
Top answer wouldn't work for me oddly, my system would not add the Path via cmd with administrator access (Not sure why).
So check this > Windows key > environment variables > system variables
And add the last line (your version may differ in the path)
Make sure you've installed the toolbelt as psql is installed by default.
However you also need to ensure you've installed a local copy of PostgreSQL; if you don't the toolbelt will be unable to find the native psql client.
Assuming you have installed a local copy of PostgreSQL, make sure you can execute psql from the command line directly (i.e make sure you PATH is set correctly ). If the command does not execute, check your PATH, if it does execute see if you can connect via the PSQL connection string provided in the Heroku control panel. If you can connect reinstall the toolbelt, if you are unable to connect provision another dev database and try again.
If there are still issues, I would suggest contacting Heroku support for assistance after verifying no API issues are listed on the status page located here.
I got rid if this annoying message on Windows by adding a path element without the spaces, i.e.
C:\Progra~1\PostgreSQL\9.4\data
instead of
“C:\Program Files\PostgreSQL\9.4\data”
I followed the instructions here: http://www.computerhope.com/issues/ch000549.htm, which worked for me if you prefer to go the point-and-click configuration of the PATH variable.
This type of error usually appears in the Windows environment, because if you do not update the PATH after installing Postgresql, heroku pg:psql command does not work.
So you need to update your PATH environment variable to add the bin directory of your Postgres installation. The directory will look like this:
C:\Program Files\PostgreSQL\<VERSION>\bin.
For more information, go to the Heroku in Local setup website:
heroku-postgresql: Local setup
I had the same problem and discovered that Heroku doesn't seem to provision the latest version of PostgreSQL by default. Where the Heroku Getting Started instructions said
heroku addons:create heroku-postgresql:hobby-dev
That provisioned a v10 database for some reason (which you can check by clicking on Heroku Postgres in the Add-ons tab of your dashboard). I deleted that database and provisioned a new database using the --version flag:
heroku addons:create heroku-postgresql:hobby-dev --version 11
As of now, at least, you can find the latest version of Postgres supported by Heroku at this link: https://devcenter.heroku.com/articles/heroku-postgresql#version-support-and-legacy-infrastructure
I'm writing this in early 2019, but according to the PostgreSQL website the next version (12) is "tentatively scheduled" for third quarter of 2019 so if you're reading this in late 2019 potentially the same problem will come up for v12 instead
On Mac you can use the following:
export PATH="/Library/PostgreSQL/12/bin/:$PATH"
The only solution that I found on Windows:
go to advanced system settings
go to environment variables
select Path variable and click Edit
add a new line and enter your bin directory path (C:\Program Files\PostgreSQL<version>\bin) and click ok
restart your terminal
enter your psql command (heroku pg:psql)
I found a lot of examples on how to change the username for specific revisions and so on.
But what I need is this:
I did a checkout with the authentication credentials of a workmate and need to change it to my credentials for future commits.
I cannot just checkout with my credentials due to the many changes that have been done already...
Anyone familiar with this?
You can change the user with
Subversion 1.6 and earlier:
svn switch --relocate protocol://currentUser#server/path protocol://newUser#server/path
Subversion 1.7 and later:
svn relocate protocol://currentUser#server/path protocol://newUser#server/path
To find out what protocol://currentUser#server/path is, run
svn info
in your working copy.
The easiest way to do this is to simply use the --username option on your next checkout or commit. For example:
svn commit --username newUser
or
svn co --username newUser
It will then be cached and will be used as the default username for future commands.
See also:
In Subversion can I be a user other than my login name?
I’ve had the exact same problem and found the solution in Where does SVN client store user authentication data?:
cd to ~/.subversion/auth/.
Do fgrep -l <yourworkmatesusernameORtheserverurl> */*.
Delete the file found.
The next operation on the repository will ask you again for username/password information.
(For Windows, the steps are analogous; the auth directory is in %APPDATA%\Subversion\).
Note that this will only work for SVN access schemes where the user name is part of the server login so it’s no use for repositories accessed using file://.
The command, that can be executed:
svn up --username newUsername
Works perfectly ;)
P.S. Just a hint: "--username" option can be executed on any "svn" command, not just update.
Go to Tortoise SVN --> Settings --> Saved Data.
There is an option to clear Authentication Data, click on the clear button, and it will allow you to select which connection you wanted to clear userid/pwd for.
After you do this, any checkout or update activity, it will reprompt for the userid and password.
If your protocol is http and you are using Subversion 1.7, you can switch the user at anytime by simply using the global --username option on any command.
When Ingo's method didn't work for me, this was what I found that worked.
for Win10 you should remove this folder and close/open your IDE
C:\Users\User\AppData\Roaming\Subversion\auth
, also in my projects no ".subversion" folders, only ".svn"
Also, for those who happened to realize too late, that they committed with the wrong credentials, the solution (after the fact) is to change the svn author of that revision: see this question
Basically the syntax is:
svn propset --revprop -r (revision_number) svn:author (new username)
Based on Ingo Kegel's solution I created a "small" bash script to change the username in all subfolders. Remember to:
Change <NEW_USERNAME> to the new username.
Change <OLD_USERNAME> to the current username (if you currently have no username set, simply remove <OLD_USERNAME>#).
In the code below the svn command is only printed out (not executed). To have the svn command executed, simply remove the echo and whitespace in front of it (just above popd).
for d in */ ; \
do echo $d ; pushd $d ; \
url=$(svn info | grep "URL: svn") ; \
url=$(echo ${url#"URL: "}) ; \
newurl=$(echo $url | sed "s/svn+ssh:\/\/<OLD_USERNAME>#/svn+ssh:\/\/<NEW_USERNAME>#/") ; \
echo "Old url: "$url ; echo "New url: "$newurl ; \
echo svn relocate $url $newurl ; \
popd ; \
done
Hope you find it useful!
I believe you could create you own branch (using your own credential) from the same trunk as your workmate's branch, merge from your workmate's branch to your working copy and then merge from your branch. All future commit should be marked as coming from you.
You could ask your colleague to create a patch, which will collapse all the changes that have been made into a single file that you can apply to your own check out. This will update all of your files appropriately and then you can revert the changes on his side and check yours in.
Tortoise on windows specific:
I attempted the above solution to no available. In my use case, the credentials where stored in the windows Credential Manager under the Windows Credential section and TortoiseSVN refused to change them by running the --username command.
You can edit the credentials by expanding the url for your repo and clicking edit.