I have created the three security groups for the testing purpose on amazon aws. Now I want to delete them. But, every time I try to delete them it gives me the error:
Group XXXXXXX:testcluster is used by groups: XXXXXXXX:testcluster-master XXXXXXX:testcluster-zookeeper
Also, there is no option to delete multiple groups. How can I delete them?
The rules will reappear in the security group if you do not save any changes done.
You will have to do the following:
Go to your security group "testcluster-zookeeper".
Delete all referenced rules to testcluster
Press the "apply rule changes" button
Go to testcluster-master repeat steps 2 and 3
I had the same problem and solved it by editing the groups I wanted to remove and then deleting each and every inbound and outbound rule. Once this change was made I was able to delete the groups that were referencing each other.
Remember to delete also reference in ElastiCache security groups.
First delete all dependencies between the groups (any rules that refer one to the other) and then you can delete the groups themselves.
The reason you are not able to delete this is simple, Security Group you want to delete is being used in some other Security Groups Inbound/Outbound rules. Please delete them and you will be good to go.
It is quite tricky to delete instances from AWS, especially EMR instances as for some reason they keep getting automatically recreated on deletion. The simplest way I found was to go to the VPC settings and delete those. Was very helpful there on to delete the rest of the stuff.
P.S. I was trying to delete all my instances, hence took this route. In fact i decided to close my account which i had created for academic purposes. I did lose a lot of money unintentionally since i left the instances on for a couple of days, my bad! :(
make sure you delete , in-bound references of chosen security group from other security groups , vice-versa. I encountered this issue , removed in-bound/outbound references to fix
Maybe you encountered the same problem as mine.
I have 2 security groups refers to each other. I tried delete them many times but didn't work. Then I realized inbound rules of them refers to each others. I deleted the inbound rules first --> delete the groups --> works
Related
I need your help. I've tried to capture an image after sysprep, and I have created an answer file (autounattend.xml). I managed to skip most of the settings, the only pending thing being the new user creation when I deploy the image on another system.
The reason I want to skip that, is because I have already defined users (admin and non-admin) on the system I've cloned, and I don't want to be prompted with creation of another user.
What I want is just to deploy the image, and to have a system identical to the one from where I captured the image. I know clonezilla can create this image, but then the security identifiers are not cleaned (generalized) as would sysprep do, which may cause issues when deployed on another system.
I saw that SkipMachineOOBE and SkipUserOOBE are deprecated and I cannot figure out a way to do that.
For the last 3 days I tried to search for a proper way to do it, but I'm not able to find anything useful.
Can you please help me with that?
Thank you in advance!
I'm trying to remove an EC2 instance that was added by mistake while trying to figure out how to deploy my API code.
Every time I terminate it, another one appears.
I now have a list of terminated instances, and 1 too many running instances.
I also have an extra EBS instance which I need to remove but can't because the Delete option is disabled.
When I read the docs it says this should work, there is no mention of the delete option not being available.
I can detach the volume, but then another one appears.
This question is similar to another one. That one suggests the problem may be caused by a cluster, but I don't have any. I followed the instructions just in case but none are listed.
There is likely an autoscaling group that is recreating it. Open the EC2 console and click Auto Scaling Groups in the left-side menu. Delete the ASG and any remaining instances should automatically be terminated.
In our D365 online environment we have multiple sandboxes and production instances. In each of these the systemuserid is different (user import was done before I joined!!). This mismatch in SystemUserId is also happening when new user is added. (my own user record for example that was added last week)
I know updating systemuserid in onPrem was unsupported but was possible but with online environment what are my best options to fix this issue? With different Guids, all references (workflow etc) are failing when moving solution across different environments.
Coming here as my last option as I have googled and looked in to SDK already.
Thanks,
hardcoding data into processes is a bad practice, makes your processes really rigid. You can create a configuration entity, stab the sys admin id there and retrieve it. If you have a custom workflow activity you will be able to retrieve the record and use it in every configuration task.
You can't update an ID at all. I usually copy my production database in all my dev environment to avoid this problem. D365 also make it easy to do so. You should take a moment between two sprints to do it because it can help to have to system user ID and entities object type code identical everywhere.
I was following railscasts to use rubber to deploy my rails app to ec2. I got the following problem:
$ cap rubber:create_staging
..... (omit successful part)
/Users/brian/.rvm/gems/ruby-1.9.3-p327/gems/excon-0.25.3/lib/excon/middlewares/expects.rb:10:in `response_call': SecurityGroupLimitExceeded => You have exceeded the number of VPC security groups allowed per instance. (Fog::Compute::AWS::Error)
how can I avoid this problem?
The issue is that by default Rubber is creating different security groups for each role. You will notice the console printing numerous "Creating Security Group #{x}" lines. The max allowed without petitioning is 5 (http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Appendix_Limits.html) without petitioning.
First run cap rubber:destroy_all.
To force Rubber to use only one security group go into rubber.yml and set...
auto_security_groups: false
isolate_security_groups: false
After that it may work, or you may get error saying security groups exists... Go here to read how to access security groups. Once in the panel delete all security groups but "default". http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_SecurityGroups.html#DeleteSecurityGroup
If you are getting errors about rules, then select the "default" user group in the AWS panel . This will bring up the rules. Delete all custom TCP rules. After this everything should work. You may need to repeat deleting groups and rules, since Rubber seems to do a terrible job of managing those.
You can request the VPC limits for your account to be raised via this form.
On the project I am working on, there are some proxy items that were added at some point from source location A to location B. However right now is not possible to check the source of the proxy and the proxy folder in B does not show anything that suggests that it's a proxy, besides the visual cue that it's grayed out.
When I analysed this article, I looked into the web.config and found this:
<proxiesEnabled>false</proxiesEnabled>
<publishVirtualItems>true</publishVirtualItems>
This seems to suggest that when the proxies were published they were published as regular items, losing any connection to their source, so since I want to recreate the proxies, due to some weird issues related to layout on the standard values item on the template not propagating correctly to the proxied items, I wanted to try to rename the old proxy folder and create a new one, however when I wanted to rename I got a modal alert with this message:
"This item occurs in other locations. If you rename it, the item will be renamed in the other locations as well. Are you sure you want to rename 'MyFoo'?"
Does this means the item still is attached to the source?
I am using Sitecore 6.2.0 (rev. 100701)
I suppose that the settings you mentioned are for master database. Now if you take a closer look at the article you reference, it lists 2 valid cases of proxies setup:
when web database also relies on proxies
when web database contains regular items only which came from publishing
These both cases assume that master database has proxiesEnabled='true'. Look, it doesn't have any sense otherwise - if proxies are disabled, the rest of the mechanism doesn't work, there are no virtual items.
And I can see proxiesEnabled='false' in the example you mentioned.
I'm not sure about the message you get. But if I need to change the proxy definition, I would do the following:
make sure proxiesEnabled='false' for web database (I guess this is your intention)
disable proxies for master database and change the proxies definition the way you want
set publishVirtualItems to true for master database
turn the proxies on for master database
make sure virtual items are in place and publish the site
Try this on some test environment and experiment to get the behavior you'd like - playing with the live site is a bad karma :)