Im trying to automate the basic monitoring option on Virtual Guests through Python, and have succeeded in ordering the Basic monitoring as well as installing Nimsoft monitor automatically. The missing step is to open up the ports (48000 to 48003) on the machines so that the monitor data can be sent.
I looked up creating network rule through API but in my case, I dont have any output when trying to output firewallServiceComponent.
In [48]: client['Virtual_Guest'].getObject(id=server_id, mask="mask[id,firewallServiceComponent[rules]]")
Out[48]: {'id': 29701179}
Can someone help in understanding how to setup Firewall rules for Virtual Guests?
Thanks!
That example is for opening ports on a VLAN firewall and not directly on the Virtual Guest. The API cannot interact with the OS level functions of your Virtual Guest. This is something that you can do manually or with the help of a Post Provisioning script.
http://knowledgelayer.softlayer.com/procedure/add-custom-provisioning-script
The firewallServiceComponent is used for VSI or BMS servers that have a hardware firewall. You can order a hardware firewall but take account that this option is only available for Monthly servers.
You can add/edit rules of hardware firewall through the API like described in I need to create a softlayer network firewall rule through REST API
If you have created the virtual guest with software firewall, you need to enter to your VSI and edit/add rules like any other OS.
To know if you have a Software firewall you can use the following REST call:
https://[user_name]:[api_key]#api.softlayer.com/rest/v3/SoftLayer_Virtual_Guest/29701179/getSoftwareComponents?objectFilter={"softwareComponents":{"softwareDescription":{"productItems":{"categories":{"categoryCode":{"operation":"firewall"}}}}}}
If you don’t have a software firewall you can create a new VSI by adding this option, or you can reload the OS. The reload will format the primary disk and will reconfigure the computing instance to the current specifications on record, before to do this I recommend you take a backup of your OS. If you are not sure to make a reload by API you can do it through portal page.
"""
Reload OS of VSI
Important manual pages:
http://sldn.softlayer.com/reference/datatypes/SoftLayer_Virtual_Guest
http://sldn.softlayer.com/reference/datatypes/SoftLayer_Virtual_Guest/reloadOperatingSystem
License: http://sldn.softlayer.com/article/License
Author: SoftLayer Technologies, Inc. <sldn#softlayer.com>
"""
import SoftLayer
USERNAME = 'set-me'
API_KEY = 'set-me'
# The id of virtual guest you wish to reload the OS
guestId = 29701179
client = SoftLayer.create_client_from_env(username=USERNAME, api_key=API_KEY)
itemPrices = [
{'id': 170009}, # Ubuntu Linux 16.04 LTS Xenial Xerus Minimal Install (64 bit)
{'id': 14625}, # Monitoring Package - Basic
{'id': 411} # APF Software Firewall for Linux
]
config = {'itemPrices': itemPrices}
try:
reload = client['SoftLayer_Virtual_Guest'].reloadOperatingSystem('FORCE', config,
id=guestId)
print(reload)
except SoftLayer.SoftLayerAPIError as e:
print("Unable to get SoftLayer_Hardware object: %s, %s " % (e.faultCode,
e.faultString))
(Take account that prices above are only examples)
I hope this help you.
Regards,
Related
I am following the security onion docs and am using vmware. I created the 2nd network adapter and set it to bridged for the monitor interface, ran the setup, selected evaluation mode, and setup the network interfaces.
My monitor interface does not see any traffic, I used wireshark to to test both interfaces and the management interface sees the traffic but the monitor interface does not. Has anyone else come across this issue?
Would be useful if you'll provide your Host OS, and versions of OS, VMWare and Security Onion- to be clear from the start and helpful for any future requests.
Out of assumption that you are using MAC-I may say it may be a known issue, see:
https://docs.vmware.com/en/VMware-Fusion/12/rn/VMware-Fusion-12-Release-Notes.html#knownissues
-here is short excerpt from it:
"Users are unable to capture transfer packets in the same subnet of a virtual network inside a virtual machine.
Virtual machine's virtual interface doesn't report packet exchanges between other virtual machines in the same subnet on Big Sur hosts.
Workaround: Use the virtual interface on the host to capture traffic information in the subnet. For example, use the interface bridge100 on macOS host to capture the traffic in the subnet"
It was reported as a known issue in Fusion 12.0, but it isn't listed in the Resolved Issues for 12.1, so it so safe to assume that it is known pending issue by now.
I accidently broke my centos VM in azure by twiddling firewall rules within it. After a reboot, the normal ssh access is not working anymore. Is there any chance to get into that VM, any console login directly to the machine somehow?
After reading the current state (April 2016) at microsoft about this, I've decided to dump the virtual machine and set it up again:
This one-directional access is just a start. Console screenshots and serial output can help identify a problem, but they are not the solution for resolving the problems. We are working on enhancements that will enable secure bi-directional access to the console of the virtual machine. This will enable additionally debugging capabilities, and, more importantly, the ability to resolve a set of common problems through the bi-directional access. Right now, I don’t have a timeline but we know this is critical.
(article)
I am working on trying to get some linux Clearcase clients to work with our existing Windows infrastructure. All of the vobs and servers are stored on Windows machines.
Using an existing vob, I was able to create a tag in the linux region to refer to the vob, and then create a view on the linux client. This client was able to connect to the vob and pull the files in when I updated the config spec. However, while it can view files, it does not have permission to edit them.
The usernames match
linux: user1
windows: DOMAIN\user1
The Clearcase admin panel is set to "Use this domain to map UNIX user and group names" with DOMAIN selected.
However, the authentication does not appear to be working. From the unix client, if I run
credmap windowsServer
I get Nobody/Nobody for the remote username and group ID. If I run from the Windows server
credmap linuxClient
It times out and I get
credmap: Error: Unable to contact albd_server on host
Investigating further albd_list on unix shows that the albd server is running, and even finds the albd_server on the windows machine.
albd_server addr = 166.20.20.81, port= 371
albd_list 166.20.17.118
albd_server addr = 166.20.17.118, port= 371
Going in the opposite direction returns
albd_list 166.20.20.81
noname: Error: Unable to contact albd_server on host '166.20.20.81'
cannot contact albd
Ping works from the windows host to the linux host, and I am even connected to the linux host by SSH from the parent at the moment.
If anyone has any ideas on what to look for next, you'd be my hero :(
You get limited ClearCase functionality when you access a ClearCase server (running on Windows) from a Linux client. To learn more, read about CCFS.
I'd suggest you to consider migrating your VOB server to Linux. This way you get all ClearCase functionality, including dynamic views.
I confirm having Vob server on windows mean they won't be fully accessible from linux client, even though the official documentation from IBM describes the CCFS setting to follow.
(See "Configure UNIX or Linux clients to access Windows VOBs", which you must have seen)
In particular, I never managed to have a credential mapping fully working from Linux to windows (the other way works well).
And you need to make sure your view storage is accessible from Linux (see "Creating a view on a NAS device")
That leaves you with inter-environment solutions, like:
CCRC (ClearCase Remote Client, for CC7.x)
ClearTeam (for CC 8.x)
See "Feature Comparison Matrix for CCRC, CTE, CCWeb, Native ClearCase GUI and SCM Adapter".
This wound up being something stupid. There was a firewall running on the linux machine blocking the albd_server port.
This also did not resolve the credential mapping issues, but it at least let me eliminate one more potential cause. Thanks
I am new to embedded linux development.I have inherited a particular way of Embedded linux development from the previous developer.
I was just wondering if there is a more industry standard way of working.
This is how he was working,
There is an ARM embedded linux board which is not on the corporate network and has a fixed IP address of 192.168.0.52.I have a virtualbox based linux host which is connected directly to this linux board via an Ethernet cable.This host has an NFS shared with the target for running the cross compiled binaries.I have to set a fixed IP address for the host of 192.168.0.50.Then I can telnet with the target to run the compiled binaries on the NFS folder. Also as the VM host is not connected to the corporate network.I cannot use the company issued SVN for version control.So what I do is have a shared folder via virtual box between Windows and Linux host and I manually keep transferring the files which I have to commit/test.
What I would I ideally like, is both networks connected to the corporate network,so that I can update the OS,use version control.Is there way by which the VM on Windows access the corporate network and also be connected to the target.IT is not willing to give a static IP to the target.If we connect the target via DHCP what is the best way to discover it on the network.Also IT is concerned about the traffic it will generate.Can I use a switch to create a subnetwork,so that the target can have a fixed address?
Another question is they are open to a linux based host as well.Is a VM based linux any worse off than a Linux PC.The only problem I have been having are networking based issues,not really Virtualbox issues.But I am curious to know if there are any limitations at all.
In order to have the VM connected to the corporate network, you can setup the VM network adapter in bridge mode.
In order to discover the embedded device, you can use the arp command (for instance: arm -i eth0 -a).
If you have got two network interfaces you could also connect the remote device directly through this interface and setup a dhcp server in your VM.
Personally, I think that with the VM you can do everything that you need (cross-compiling the Kernel and bootloader and creating the remote File System). I have been using a VM for embedded linux development on a AT91SAM board without problems at all.
I'm setting up a linux server in a VM for my development.
Previously I've had PHP, MySQL etc etc all installed locally on my Mac. Apart from being a security risk, it's a drag to maintain and keep up to date, and there's a risk that an OS upgrade will wipe part of your setup out as the changes you make are fairly non-standard.
Having the entire server contained within a VM makes it easily upgradable and portable between machines. It means I can have the same configuration as the destination server and with shared folders even if the VM gets corrupted my work is safe on the host machine.
Previously with the local installation I was able to develop on convenient URLs like http://site.dev. I'd quite like to carry this over to the VM way of development but I'm struggling to figure out how, if it's possible at all.
Here's the problem:
In Bridged mode, the VM is part of the same network as the host. This is great but I can't choose a fixed IP address as I may be joining other networks and that address may be taken already. I'd like a consistent way of addressing my VM.
In NAT mode I can't directly address the VM without using port forwarding. I can use http://site.dev if I use the hosts file to forward that to localhost and then localhost:8080 forwards to the vm:80. The trouble is I have to access http://site.dev:8080 which is inconvenient for URL construction.
Does anyone know a way around this? I'm using ubuntu server and virtualbox.
Thanks!
The answer is to define a separate host-only network adapter and use that for host->guest communication.
You can do this by powering down the guest and adding the adapter in the VM settings. Once that's done you can boot the guest again and configure the new network interface however suits you best. I chose a fixed IP address in an unused range.