Just found that SQLPLUS would parse the first line of a sql script as connect string if I do not include the credentials when invoke sqlplus in the terminal, details are listed below:
I have a sql script named runme.sql:
scott/tiger#//localhost:1522/orcl
select * from dual;
exit;
If I invoke sqlplus as sqlplus #runme.sql , sqlplus could parse the first line and connect to database and run the sql. Can anyone point me to the documentation for this if there is any ? Also what are the advantages for supporting this syntax ?
The documentation is usually a good place to start. Note the warning if you supply the username/password on the command line; providing at least the password when prompted is more secure, and particularly in Unix-type environments means the credentials don't appear in the output of a ps command.
Putting either the password or both the username and password in a script automates that, but of course you have to then ensure that the script can't be viewed by anyone who shouldn't know the credentials.
As LalitKumarB notes in a comment, hardcoding the password anywhere is a security risk. If you're running scripts interactively then allow the slight inconveince of being prompted each time. (Which isn't really inconvenient when compared to the damage that could be done from the credentials being misused, and subsequent inconvenience of recovering, and/or finding a new job). If the script isn't being run interactively then use the scheduler rather than, say, cron. You can also use Oracle Wallets for greater security without so much inconvenience.
Specifically for your query about it parsing the first line, the documentation says:
If you do not specify logon but do specify start, SQL*Plus assumes that the first line of the script contains a valid logon.
In this context 'start' is the same as using # on the command line to supply the script name.
Related
As Part of data Analysis, I need to connect excel macros with unix, fire my shell script from a macro, and get the output file back to excel. I tried using winsock, but it didn't work
This is not a very clear question...
but i suggest to split the problem into parts
test the shell script to make sure it outputs exactly what you want (including carriage returns / whitespace / other fromatting that might confuse Windows or Excel)
test your method of connecting from Windows to Unix. make sure you can run a command from PowerShell which logs in to the unix machine, runs the script, and returns the result
test your Excel macro. ensure it has permission to make the connection you made from PowerShell
You'll have better luck on StackOverflow if you post a piece of code (or network details) and the error message you got from that code.
When using the Shipit automation engine I found that trying to execute commands with "sudo" from an user other than root (let's call it "devuser") results in the connection closing without the command being executed.
This is a command that I'm trying to execute:
shipit.remote('sudo pwd');
Note that, on the target machine, "devuser" can execute everything with "sudo", without being asked his/her password (it's a choice of the target system).
Also note that everything invoked without "sudo" (and that obviously doesn't need elevated permission) gets executed prefectly fine by Shipit.
E.g.this one works just fine:
shipit.remote('pwd');
The question at this point is: am I doing something wrong or is it this way by design (e.g. to avoid privileges escalation)?
If it's the latter: is there a way to work this limitation around?
simple hack for that is to set user inside each command that you are running with shipit. This is little overhead especially if there are a lot of commands but it will do the trick. Command for that is :
su - <user> -c "<command>"
In your case :
shipit.remote('su - devuser -c "pwd"');
You were on right track with your example.
Best regards,
Nikola
I am trying to implement an online terminal UI with jsch as backend.
I need to display the userinfo ie [username#Machine ~]$ information in the UI.
Since the outputstream simply sends the bytes, it is difficult to distinguish the userinfo with the real command output. Is there any way to distinguish the same?
In general, no.
If you have a shell channel, all you see is the output from the user's remote shell, including the prompt and the actual command output. You can try to parse that. In simple cases this will work, but in general it is impossible, as every command could output a prompt-like string.
The username should be known to you (it should be the same as you used for login), the server name is a bit trickier.
An idea worth exploring might be to set a special prompt delimited by character sequences which are unlikely to occur in "normal" command output – set the PROMPT variable in your shell.
You could circumvent that problem by not using actually a shell channel, but an individual exec channel for each command – but then you'll have to interpret commands like cd yourself and keep track of the current directory, and add a cd command before the actual command in each exec channel. You might want to have an sftp channel open in parallel to keep track of the directories (and list files, and so on).
What do you thing it will be the optimal method of passing passwords to different applications.
Giving the password as a command line argument is not acceptable because this will be visible in logs - especially in an automation system.
At this moment I'm considering two possibilities: providing the password in a file or temporary setting it in an environment variable.
Please give your recommendation and explain it.
Is there any way to automate the user input in a ksh script?
I realize that in many instances you can create an expect script to do exactly what I am saying, but expect is not installed on the server and there is no chance of that occurring in the near future. But I still need a method of automating user input so the only reaction required is to start the script.
If you have the complete set of "user" input, you can redirect stdin:
script.ksh <userinputfile
If you have some of it, or generate it on the fly, you can use "hereis" documents.
If you are going to be parsing prompts, the easiest way, as you mention, the easiest way is to use Expect. Even if Expect isn't available on the server, it'll be easier for you to include as much Tcl/Expect as necessary to do your parsing than to rewrite and redebug it.