Post #101,765
5/13/03 10:39:11 PM
|
One possible hint
This is something I'm looking at but am running into authentication issues with. A 'sudo' enabled script using password authentication might work. But I haven't figured out how to enable password (SQL Server) auth rather than NT auth on SQL Server. \r\n\r\n The tool is [link|http://www.sqsh.org/|sqsh], the SQL Shell. Apt-gettable on your desired distribution. \r\n\r\n As indicated, I've looked at it but can't get over the authentication hurdle. --\r\n
Karsten M. Self [link|mailto:kmself@ix.netcom.com|kmself@ix.netcom.com]\r\n
[link|http://kmself.home.netcom.com/|http://kmself.home.netcom.com/]\r\n
What part of "gestalt" don't you understand?\r\n
[link|http://twiki.iwethey.org/twiki/bin/view/Main/|TWikIWETHEY] -- an experiment in collective intelligence. Stupidity. Whatever.\r\n
\r\n
Keep software free. Oppose the CBDTPA. Kill S.2048 dead.\r\n[link|http://www.eff.org/alerts/20020322_eff_cbdtpa_alert.html|http://www.eff.org/alerts/20020322_eff_cbdtpa_alert.html]\r\n
|
Post #101,769
5/13/03 11:27:42 PM
|
Don't see how it applies
I need to trigger running a package in the database context. There are several ways that I know how to do it.
1) Schedule it to run.
2) In the Admin->SQL Agent screen, right click->Run. This can only be done of you are an admin.
Other than that, if I am in the DTS panel, and run it, it runs using my current context. This means drives mounted are through the current PC, not from the frame of reference from the server itself.
I'd LOVE to know what the underlying SQL command would be to issue an immediate run via the schedule program. Hell, it might be OK to have the Linux box gain access to a shell on the primary SQL/Server box and issue the dtsrun from there, which would take care of the server context issue.
If I knew that, then I might be able to use the SQSH that you pointed me to. I already have both password auth and NT auth on my user ID. I can't tell you how it was done though since I didn't set it up. I know I have 2 IDs though. They initially just gave me NT auth and I screamed that I needed to be able to automate using password so they gave me another ID. On the user lists I see myself as just "broom" and as "domain\\broom"
The key issue is to setup for some OTHER user to run this stuff so I can hand production off to the other person without granting them DBA just for this type of task.
It was also fun setting it up so the SQL/Server box could read and write files on a Samba share on the Solaris side using NT auth on Samba. We ended up moving the SQL/Server box to a different domain to make it work. I had to get the newbie heavy accent asian dba in sync with the newbie Russian windows admin along with the open source evangelist (HOW DARE YOU USE SQL/SERVER!) Unix admin all in sync.
|
Post #101,821
5/14/03 10:09:07 AM
|
Works
Installed FreeTDS and SQLSH.
Needed:
freetds-0.61.tgz
./configure --with-tdsver=8.0 --with-ssl
Also had to hand symlink a misinstalled lib.
Logged in:
sqsh -S AFI
Did test select.
[2] AFI.AFI.1> select count(*) from afi.dbo.afi_detail_curr;
-----------
4007712
Did job submit:
[6] AFI.AFI.1> use msdb;
[7] AFI.msdb.1> EXEC sp_start_job @job_name = 'exp_hist_finder_sched';
Job 'exp_hist_finder_sched' started successfully.
[8] AFI.msdb.1>
Life is good.
Or as good as it can be while I'm force to use SQL/Server
My permissions got broke and I'm waiting on the DBA
to come in to do the wrapper as described by Chris.
|
Post #101,915
5/14/03 7:05:20 PM
|
OK, too
Figured out the authentication thing. Remind me to post my SQL Server chamberpot of horrors sometime... \r\n\r\n Apparently, a domain user (eg: DOMAIN\\USERNAME) cannot use password authentication. So create a new user. Naturally, "USERNAME", matching "DOMAIN\\USERNAME" isn't clearly distinguished by SQL Server from the domain user. So delete that and create a fresh account and set a password. \r\n\r\n \r\n\r\n$ sqsh -S 192.168.1.40 \r\nsqsh-2.1 Copyright (C) 1995-2001 Scott C. Gray\r\nThis is free software with ABSOLUTELY NO WARRANTY\r\nFor more information type '\\warranty'\r\nPassword: \r\n1> \r\n \r\n \r\n\r\n ...and queries work. \r\n --\r\n
Karsten M. Self [link|mailto:kmself@ix.netcom.com|kmself@ix.netcom.com]\r\n
[link|http://kmself.home.netcom.com/|http://kmself.home.netcom.com/]\r\n
What part of "gestalt" don't you understand?\r\n
[link|http://twiki.iwethey.org/twiki/bin/view/Main/|TWikIWETHEY] -- an experiment in collective intelligence. Stupidity. Whatever.\r\n
\r\n
Keep software free. Oppose the CBDTPA. Kill S.2048 dead.\r\n[link|http://www.eff.org/alerts/20020322_eff_cbdtpa_alert.html|http://www.eff.org/alerts/20020322_eff_cbdtpa_alert.html]\r\n
|
Post #102,145
5/15/03 5:30:34 PM
|
OT: how is DOMAIN\\USER kind of login supported in SAMBA
client?
I've got bitten once trying to acces a share protected that way. Had to do it from a Windows machine in the end.
--
Less Is More. In my book, About Face, I introduce over 50 powerful design axioms. This is one of them.
--Alan Cooper. The Inmates Are Running the Asylum
|
Post #102,174
5/15/03 10:16:03 PM
|
RTFM
Samba is trivial to set up with swat. The difficulties are in the bizarre syntax and confusing wording of the configuration file. Of course, if you go into Samba without understanding LAN Manager (the most brain dead NOS of all time, and so something that is easy to understand), then you will get out of it what you took into it.
The only vitally important parameters are security (share, user, domain) and OS level (for NetBIOS browser elections). The actual problems happen with synchronizing users on the domain vs. UNIX. That is simple with smbadduser. If you remember that ALL LAN Manager networking is really peer-to-peer, you've got it licked.
There was a parallel in the days of NT 3.51 Server, which was really the same binary thing as NT 3.51 Workstation. By editing the registry, you could convert WS into Server or even a DC - really, the same thing as security=share vs. security=user vs. security=domain. It's really quite trivial. Oh that was a hateful operating system.
Bring it on, game boy.
-drl
|
Post #102,187
5/16/03 2:55:36 AM
|
Consider winbind.
Peter
[link|http://www.debian.org|Shill For Hire]
[link|http://www.kuro5hin.org|There is no K5 Cabal]
[link|http://guildenstern.dyndns.org|Blog]
|
Post #102,270
5/16/03 12:56:46 PM
|
Client. Client. Client. Damn it.
--
Less Is More. In my book, About Face, I introduce over 50 powerful design axioms. This is one of them.
--Alan Cooper. The Inmates Are Running the Asylum
|
Post #102,271
5/16/03 1:04:58 PM
|
As Petah said...
Look into winbind. You can set up Windows users as Unix users, in the style of username = "MYDOMAIN+arkadiy". You can then log on as that user on the unix box, and winbind will hand off the authentication on the share to your Windows domain controllers/AD.
Many fears are born of stupidity and ignorance -
Which you should be feeding with rumour and generalisation.
BOfH, 2002 "Episode" 10
|
