Sunday, July 29, 2012
Wednesday, July 18, 2012
Mhmmm ... I used to got to MC like this
Friday, July 6, 2012
root@cloud:/var/log# nmap -vvv -O --osscan-guess 192.168.88.133 Starting Nmap 5.00 ( http://nmap.org ) at 2012-07-05 20:57 CEST NSE: Loaded 0 scripts for scanning. Initiating ARP Ping Scan at 20:57 Scanning 192.168.88.133 [1 port] Completed ARP Ping Scan at 20:57, 0.08s elapsed (1 total hosts) Initiating Parallel DNS resolution of 1 host. at 20:57 Completed Parallel DNS resolution of 1 host. at 20:57, 0.00s elapsed DNS resolution of 1 IPs took 0.00s. Mode: Async [#: 1, OK: 0, NX: 1, DR: 0, SF: 0, TR: 1, CN: 0] Initiating SYN Stealth Scan at 20:57 Scanning 192.168.88.133 [1000 ports] Discovered open port 443/tcp on 192.168.88.133 Discovered open port 4443/tcp on 192.168.88.133 Discovered open port 80/tcp on 192.168.88.133 Discovered open port 6000/tcp on 192.168.88.133 Discovered open port 9090/tcp on 192.168.88.133 Discovered open port 7676/tcp on 192.168.88.133 Completed SYN Stealth Scan at 20:57, 2.69s elapsed (1000 total ports) Initiating OS detection (try #1) against 192.168.88.133 Host 192.168.88.133 is up (0.0057s latency). Scanned at 2012-07-05 20:57:33 CEST for 4s Interesting ports on 192.168.88.133: Not shown: 994 closed ports PORT STATE SERVICE 80/tcp open http 443/tcp open https 4443/tcp open pharos 6000/tcp open X11 7676/tcp open unknown 9090/tcp open zeus-admin MAC Address: 48:44:F7:BB:F6:89 (Unknown) Device type: general purpose Running: Linux 2.6.X OS details: Linux 2.6.17 - 2.6.28 TCP/IP fingerprint: OS:SCAN(V=5.00%D=7/5%OT=80%CT=1%CU=41499%PV=Y%DS=1%G=Y%M=4844F7%TM=4FF5E3A1 OS:%P=x86_64-unknown-linux-gnu)SEQ(SP=C6%GCD=1%ISR=D2%TI=Z%CI=Z%II=I%TS=8)O OS:PS(O1=M5B4ST11NW5%O2=M5B4ST11NW5%O3=M5B4NNT11NW5%O4=M5B4ST11NW5%O5=M5B4S OS:T11NW5%O6=M5B4ST11)WIN(W1=16A0%W2=16A0%W3=16A0%W4=16A0%W5=16A0%W6=16A0)E OS:CN(R=Y%DF=Y%T=40%W=16D0%O=M5B4NNSNW5%CC=Y%Q=)T1(R=Y%DF=Y%T=40%S=O%A=S+%F OS:=AS%RD=0%Q=)T2(R=N)T3(R=Y%DF=Y%T=40%W=16A0%S=O%A=S+%F=AS%O=M5B4ST11NW5%R OS:D=0%Q=)T4(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F=R%O=%RD=0%Q=)T5(R=Y%DF=Y%T=40%W=0% OS:S=Z%A=S+%F=AR%O=%RD=0%Q=)T6(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F=R%O=%RD=0%Q=)T7( OS:R=Y%DF=Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)U1(R=Y%DF=N%T=40%IPL=164%UN=0 OS:%RIPL=G%RID=G%RIPCK=G%RUCK=G%RUD=G)IE(R=Y%DFI=N%T=40%CD=S) Uptime guess: 0.060 days (since Thu Jul 5 19:31:43 2012) Network Distance: 1 hop TCP Sequence Prediction: Difficulty=198 (Good luck!) IP ID Sequence Generation: All zeros Read data files from: /usr/share/nmap OS detection performed. Please report any incorrect results at http://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 4.58 seconds Raw packets sent: 1029 (46.036KB) | Rcvd: 1017 (41.439KB) root@cloud:/var/log#
Sunday, November 13, 2011
Today I would like you to "start from the scratch" when looking at your datacenter services!
Starting from the upper endpoint, the end-user of your service, I will go down and list the dependencies of the service from one step to the next.
Please notice that those dependencies are also true for any type of Cloud Computing services!
- End-user (Person)
- The Request (Software)
- IP-address and Port (Software)
- Operating System (Software)
- A Virtual Machine (Software)
- Physical Systems (physical Hardware!)
- Datacenter services should be high-availabe.
- The actual service is "software" only.
- The service sadly still depends on "hardware" (even if virtualized).
- ... and hardware will break at some point in time
If any kind of the service configuration and/or data is "stored" locally on the physical systems (the Virtualization host) a failure of the hardware will also cause a failure (and possible outage) of the service.
About "physical hardware" in our Universe:
Everything (i really mean everything) in this Universe is constantly changing. The only thing which is not changing is that everything IS changing. This means every physical system will break at some point in time!
... or lets rephrase it via Murphy's law:
Make absolutely sure that no bit of data belonging to the service is stored locally on physical systems (Virtualization Hosts). Avoid binding any of your services (software only) to physical server (hardware)!
With Cloud Zones, native VMware vSphere/ESX support and lots of improvements to the base system and plugins, openQRM 4.9 opens up new dimensions in professional datacenter management.
These are the highlights of the new version:
- Cloud Zones
Implement Cloud Computing services across multiple datacenter locations, each running their own openQRM infrastructure - seamlessly managed with a new infrastructure layer on top of it all.
- Rewritten VMware vSphere/ESX support
openQRM now natively manages VMware ESX(i) hosts and guests, using the latest and greatest features the VMware vSphere/ESX API has to offer.
- Comprehensive, automatic Linux and Windows installation
Seamlessly attach existing Cobbler, FAI, LinuxCOE and/or Opsi environments to your openQRM infrastructure and forget about initial provisioning hassle.
For more details please have a look at the Changelog.
The new openQRM 4.9 release is now freely available under GPLv2 license for download at https://sourceforge.net/projects/openqrm/files/
The project's subversion repository got updated with the 4.9 release code.
Thanks for this release are especially going to the openQRM Enterprise team for sponsoring new features and contributing a lot of development and QA effort. Many thanks go to everybody in the openQRM community, as well, for providing us with useful feedback and bug reports.
Project Manager openQRM, on behalf of the openQRM Team
Monday, October 25, 2010
... dragging and dropping VMs in the openQRM Cloud is almost too simple.
(and actually those are 102 nodes)