I have a Windows Server VM with the ADF Integration Runtime installed running under a local account called deploy. This account is a member of the local admins group. The server is not domain-joined.
I created a new linked service (File System) and pointed it to a csv file on the root of the C drive as a test. When I test the connection I get Connection failed.
Error occurred when trying to access the file in Folder 'C:\etr.csv', File filter: ''. The directory name is invalid. Activity ID: 1b892702-7cc3-48d5-83c7-c680d6d15afd.
Any ideas on a fix?
The linked service needs to be a folder on the target machine. In your screenshot, change C:\etr.csv to C:\ and then define a new dataset that uses the linked service to select etr.csv.
The dataset represents the structure of the data within the linked data stores, and the linked service defines the connection to the data source. So the linked service should point to the folder instead of file. It should be C:\ instead of C:\etr.csv
I have a use case where I need to connect to 2 different DBS using 2 different accounts. And I am using Kerberos for authentication.
Is it possible to create multiple Kerberos tickets on same machine?
kinit account1#DOMAIN.COM (first ticket)
kinit account2#DOMAIN.COM (second ticket)
Whenever I do klist, I only see most recent ticket created. It doesn't show all the tickets.
Next, I have a job that needs to first use ticket for account1 (for connection to DB1) and then use ticket for account2 (for DB2).
Is that possible? How do I tell in DB connection what ticket to use?
I'm assuming MIT Kerberos and linking to those docs.
Try klist -A to show all tickets in the ticket cache. If there is only one try switching your ccache type to DIR as described here:
DIR points to the storage location of the collection of the credential caches in FILE: format. It is most useful when dealing with multiple Kerberos realms and KDCs. For release 1.10 the directory must already exist. In post-1.10 releases the requirement is for parent directory to exist and the current process must have permissions to create the directory if it does not exist. See Collections of caches for details. New in release 1.10. The following residual forms are supported:
DIR:dirname
DIR::dirpath/filename - a single cache within the directory
Switching to a ccache of the latter type causes it to become the primary for the directory.
You do this by specifying the default ccache name as DIR:/path/to/cache on one of the ways described here.
The default credential cache name is determined by the following, in descending order of priority:
The KRB5CCNAME environment variable. For example, KRB5CCNAME=DIR:/mydir/.
The default_ccache_name profile variable in [libdefaults].
The hardcoded default, DEFCCNAME.
A user cannot checkout from windows client ClearCase ( see picture)
And yet, the same user can checkout from a unix client.
Why?
Thanks for your answer #VonC
Please find my below findings
Here the primary group of the vob is
/usr/atria/bin/cleartool desc vob:/vobs/MCT
versioned object base "/vobs/MCT"
created 2010-03-03T16:42:52+02:00 by Admin.WTD (wtadmin.wtusers#frmrssucc004)
"MSS Access"
master replica: xh_mct_athens#/vobs/MCT
replica name: xh_mct_athens
VOB family feature level: 5
modification by remote privileged user: allowed
atomic checkin: disabled
VOB ownership:
owner *********servername***/ca_xhvadm
group eelinnis.emea.nsn-net.net/ccusers_xhaul_athens
ACLs enabled: No
Attributes:
FeatureLevel = 5
Hyperlinks:
AdminVOB -> vob:/vobs/MPTADMIN
And user id output is
id karageor
uid=61333334(karageor) gid=8003(ccusers_xhaul_athens)
groups=7000(hostingusers_cic_athens),8003(ccusers_xhaul_athens)
and on the windows the primary group is set as
Is the unix group ccusers_xhaul_athens has to be set as windows primary group on system variable
Kindly confirm
The main factor which explain a permission issue in a ClearCase interop (Windows ClearCase client - Linux ClearCase server) is the CLEARCASE_PRIMARY_GROUP environment variable.
That variable (CLEARCASE_PRIMARY_GROUP) needs to:
be set to the primary group of the vob of the element the user is trying to checkout (primary or secondary: type cleartool describe -l vob:\YourVob to list them)
be the same value as the primary group of the Linux user (who can successfully checkout the same element in his/her Linux ClearCase view): type id -a to see that primary group eelinnis.emea.nsn-net.net/ccusers_xhaul_athens
Make sure on Windows the user is not launching the client with another account (Administrator, or System account), and the CLEARCASE_PRIMARY_GROUP is set.
(and the number of group is not too high)
You can use the creds utility to see your credentials.
See more at "ClearCase won't allow Check-In" and use the credmap utility to verify the group assignments between Windows and Unix.
Type set CL in a CMD shell in Windows to see the actual full value of the CLEARCASE_PRIMAY_GROUP environment variable (??_EE_CLEARCASE_USERS_XHAUL_ATHENS)
You need to see if that group maps to the Linux one.
Check also the protection associated to your view. See fix_prot on Windows here.
In my current code base, when i create a VM, DNS name is being dynamically set as same as the instance name. For example, consider if my VM name is "anandInstance", DNS name of the name is being generated as "anandInstance.cloudapp.net". Is there a way to change the DNS name like "dns1.cloudapp.net" during the creation thru REST API??
"Connect to existing VM" , is it possible to achieve this option through REST call? In case "connect to existing.." option , we are getting a list of vms/services to choose and VM is getting created successfully. How to achieve the same using API.
Thanks
In my current code base, when i create a VM, DNS name is being
dynamically set as same as the instance name. For example, consider if
my VM name is "anandInstance", DNS name of the name is being generated
as "anandInstance.cloudapp.net". Is there a way to change the DNS name
like "dns1.cloudapp.net" during the creation thru REST API??
I don't think it is possible. Imagine what a nightmare in the portal would become if you were able to do so? How would you link a Cloud Service (whatever.cloudapp.net) to an actual deployment (MyDemoVm123). However you can use your own domain and have CNAME records pointing to your "want-to-change-for-some-reason.cloudapp.net" (frankly I surely think that soon we will use even longer names)
"Connect to existing VM" , is it possible to achieve this option
through REST call?
Connection to a VM is essentially opening a RDP session. If it a windows VM, you can try using the Download RDP file API call. Once you get the file, just start it with "process.start". If it is linux VM, just start SSH client on port 22 (or one you have defined) from the Cloud Service DNS name you have.
UPDATE
From the azure portal,for stand alone machineoption, we are able to give the dns name with deafult cloudoneapp.net. How to do the same
through the rest api call.any specfic paramter is there to specify the
same?
When you are using the REST API, you first create a Cloud Service (still named hosted service in the REST API) where your machine will be hosted. Here you give the name for that hosted service (the dns name with deafult cloudoneapp.net). Then you call the Create Virtual Machine Deployment API action.
In case "connect to existing.." option , we are getting a list of vms/services to choose and VM is getting created successfully. How to
achieve the same using API.
When you want to get list of all VMs, just get a list of all Hosted Services, then get properties of each and make a guess whether it is a VM or a Cloud Service (maybe by querying for Properties of each service). I don't see a direct access to the list of Virtual Machines. But as this feature being PREVIEW, things might change in the future.
Hope my answer is clear?
I'm trying to create a trigger on a table in my Amazon RDS database, and I can't seem to make it happen.
I tried to create a trigger on a table in the mysql client I use (Navicat), and got the error that I needed the SUPER privilege to do so. After some searching, I found that you could SET GLOBAL log_bin_trust_function_creators = 1 to get around this. I tried that using these instructions: http://getasysadmin.com/2011/06/amazon-rds-super-privileges/ (and then restarting the DB server for good measure), but no luck.
I also tried creating the trigger and setting the variable via the mysql commmand line to make sure Navicat wasn't adding anything unwanted to my sql commands, but that failed, too. It also seems from searching that there's no way to grant yourself the SUPER privilege.
So ... is creating a trigger possible in RDS?
Its easy!
Open the RDS web console.
Open the “Parameter Groups” tab.
Create a new Parameter Group. On the dialog, select the MySQL family compatible to your MySQL database version, give it a name and confirm.
Select the just created Parameter Group and issue “Edit Parameters”.
Look for the parameter ‘log_bin_trust_function_creators’ and set its value to ’1′.
Save the changes.
Open the “Instances” tab. Expand your MySQL instance and issue the “Instance Action” named “Modify”.
Select the just created Parameter Group and enable “Apply Immediately”.
Click on “Continue” and confirm the changes.
Again, open the “Instances” tab. Expand your MySQL instance and issue the “Instance Action” named “Modify”.
Dont forget: Open the “Instances” tab. Expand your MySQL instance and issue the “Instance Action” named “Reboot”.
Via - http://techtavern.wordpress.com/2013/06/17/mysql-triggers-and-amazon-rds/
No it is actually not impossible it just takes far too much extra work.
First off it seems to be impossible to apply Super Privileges to a default parameter group.
So what I had to do was to create a new DB Parameter group either through the Console, or the CLI.
What I found was, the key is that the default region was not the region I was trying to use so I had to use a --region parameter to apply it to the group in the correct region where I was deploying my DB Instance
rds-create-db-parameter-group --db-parameter-group-name allow-triggers --description 'parameter group to allow triggers' --region your-region
Next I had to create a DB Instance which used that parameter group. (Again through the console or CLI)
rds-create-db-instance
Then I had to modify the Parameter group to allow log_bin_trust_function_creators only accomplishable through the CLI
rds-modify-db-parameter-group --db-parameter-group-name yourgroupname --region yourRegion --parameters 'name=log_bin_trust_function_creators,value=true,method=immediate'
Lastly I had to modify the created DB Instance to allow triggers, also CLI only.
rds-modify-db-instance --db-instance-identifier your-db-instance-id --db-parameter-group-name allow-triggers --apply-immediately
In addition to the parameter group modification that others have already mentioned, there is a further challenge that arises when using a MySQL database dump (via mysqldump) to create triggers in an AWS RDS instance. You may get a message like this:
ERROR 1227 (42000) at line 875: Access denied; you need (at least one of) the SUPER privilege(s) for this operation
This happens because the dump contains "definer" entries with a username that's different than your RDS master username. One solution is to replace the definer username with your RDS master username. Another solution is not to use mysqldump to create your database.
See this blog post for more information:
http://www.percona.com/blog/2014/07/02/using-mysql-triggers-and-views-in-amazon-rds/
EDIT: It turns out Multi-AZ for MySQL uses "physical replication" and not logical replication, so this may not be correct. At least that's what their documentation says: https://aws.amazon.com/rds/details/multi-az/ - I have asked on their forums what this means, but did not get a reply. What's weird is that my RDS Multi-AZ instance claims it's a "master in a replication setup", even though I have no read replicas.
As the question has already been addressed, this is a comment more than an answer:
I'm surprised nobody takes into account why this feature is not available as a default. Amazon wouldn't disable it just to make people's lives harder.
In a master/slave replication it can be dangerous to use stored procedures and triggers that modify data (as in perform queries other than SELECT).
Please have a read below before disabling this restriction in a master/slave setup, which Amazon RDS is when you use Multi-AZ (and you should, for production at least).
http://dev.mysql.com/doc/refman/5.6/en/stored-programs-logging.html
I followed the above but it did not work for me. I spent almost a day to figure out why it is not working and now I know why. I am listing down steps that I followed to make it work.
Created mysql parameters group using aws web console (make sure that it should have same family as the default parameter group. Earlier, I had created a parameter group but it had different family and so it did not work. This is critical step.
Using aws web console change value of log_bin_trust_function_creators to 1
Apply new parameter group. This is another critical step
rds-modify-db-instance –I $AWS_ACCESS_KEY –S $AWS_SECRET_KEY –region $EC2_REGION \ –db-instance-identifier $DB_INSTANCE \
–db-parameter-group-name $DB_GROUPNAME \
–apply-immediately
You need RDSCli from - http://s3.amazonaws.com/rds-downloads/RDSCli.zip
Then verify if parameter group is associated with your db instance
rds-describe-db-instances \
–I $AWS_ACCESS_KEY \
–S $AWS_SECRET_KEY \
–region $EC2_REGION
And then reboot before you try creating trigger
rds-reboot-db-instance \
–I $AWS_ACCESS_KEY \
–S $AWS_SECRET_KEY \
–region $EC2_REGION \
–db-instance-identifier $DB_INSTANCE
Remember to set below environment variable before you try above commands.
export AWS_ACCESS_KEY=’*****’
export AWS_SECRET_KEY=’*****’
export EC2_REGION=’region’
export AWS_RDS_BIN=”$AWS_RDS_HOME/bin”
export PATH=$PATH:$AWS_RDS_BIN
export JAVA_HOME=c:/jdk1.6_25 (in most cases this is already set)
Thanks to http://blog.iprofs.nl/2013/03/20/rds-database-triggers-for-mysql/ for full details.
AWS lays out how to enable functions and triggers in this post
Create a DB parameter group for your MySQL instance:
Sign in to the AWS Management Console and open the Amazon RDS console.
In the navigation pane, choose Parameter Groups.
Choose Create Parameter Group. The Create Parameter Group window appears.
For Parameter Group Family, choose the parameter group family.
For Group Name, type the name of the new DB parameter group.
For Description, type a description for the new DB parameter group.
Choose Create.
Important
After you create a DB parameter group, you should wait at least 5 minutes before creating your first DB instance that uses that DB parameter group.
For more information about creating a DB parameter group, see Working with DB Parameter Groups - Creating a DB Parameter Group.
Modify the newly created parameter group and set the following parameter:
In the navigation pane, choose Parameter Groups. The available DB parameter groups appear in a list.
In the list, select the parameter group you want to modify.
Choose Edit Parameters and set the following parameter to the specified value:
log_bin_trust_function_creators = 1
Choose Save Changes.
Important
After you modify a DB parameter group, you should wait at least 5 minutes before creating your first DB instance that uses that DB parameter group.
For information about modifiying a DB parameter group, see Working with DB Parameter Groups - Modifying Parameters in a DB Parameter Group.
Associate your RDS DB instance with the new or modified DB parameter group:
In the navigation pane, choose Instances.
Select the DB instance you want to associate with a DB parameter group.
On the Instance Actions menu, choose Modify.
In the Modify DB Instance dialog box, under Database Options, choose the parameter group you want to associate with the DB instance. Changing this setting does not result in an outage. The parameter group name changes immediately, but the actual parameter changes are not applied until you reboot the instance without failover.
Apply changes by rebooting the instance.
For me, it worked as the #foxybagga's answer suggest, but I needed to update the generated sql's dump (from mysqlworkbench) to have CURRENT_USER as the DEFINER
ie:
DELIMITER ;;
/*!50003 CREATE*/ /*!50017 DEFINER=CURRENT_USER*/ /*!50003 TRIGGER `sod_db`.`date`
BEFORE INSERT ON `sod_db`.`CashOut`
FOR EACH ROW
BEGIN
SET NEW.created = NOW();
END */;;
DELIMITER ;
/*!50003 SET sql_mode = #saved_sql_mode */ ;
/*!50003 SET character_set_client = #saved_cs_client */ ;
/*!50003 SET character_set_results = #saved_cs_results */ ;
/*!50003 SET collation_connection = #saved_col_connection */ ;
I hope this helps someone is having the same problem.