Thursday, 28 April 2016

How to run a Minecraft Server in the Oracle Cloud


UPDATE: this is an old post based on the Oracle Cloud Infrastructure Classic (OCI-C). There is an updated version of this post for running Minecraft on the Oracle Cloud Infrastructure (OCI).

---8<--------------------------------------------------------------------------------------------------------------------

This handson tutorial shows the steps needed to run a Minecraft Server on the Oracle Compute Cloud Service



Let's start in the My Services Dashboard and click on the Oracle Compute Cloud Service.


In the list of existing instances, click on Create Instance.


Choose the Oracle Linux 6.6 image, the smallest Shape should be more than sufficient.


Don't touch the defaults on the second page.


The Minecraft server is so small, that we do not need additional storage.


The SSH public key is important. If you don't have one, refer to the Oracle Cloud Documentation. What you need here are the contents of the .pub file, if you follow the documentation.


Take a last look at the summary and click on Create.


Wait a few minutes until the instance has been created. Then click on the menu icon on the right, chose View and copy the public IP address.


Now open your SSH client, like PuTTY in this example. Here paste the public IP address, give the session a name and click Save.


Enter the Auto-login username 'opc'.


Under Connection/SSH/Auth choose you private key file. Then save again and open your session.


Pull the Minecraft server directly from its publisher via

wget https://s3.amazonaws.com/Minecraft.Download/versions/1.9.2/minecraft_server.1.9.2.jar

Then start it:

java -jar minecraft_server.1.9.2.jar

After the first start, the server terminates immediately, because you have to accept the EULA first.


It created a new file eula.txt. Open it in vi and change the content to eula=true.


As the Minecraft server has an interactive console, it should be accessible even when the SSH console has been closed in between. I prefer to use screen for that, which is already preinstalled in Oracle Linux. So open a new screen with

screen -S minecraft


Now start the Minecraft server again. We are done with SSH, close the screen session via CRTL-A D or just close your PuTTY window. If you want to reconnect to your Minecraft server from a new SSH session, just type


screen -d -r minecraft


Back in the Oracle Cloud Services. The Minecraft server is running, but is blocked by the firewall. So we do need to configure that.


Click on the Network tab. The only port, that has been opened, is the one for SSH which we just used.


Under 'Security Applications', click on Create Security Application


The port for the Minecraft Server is 25565.


Now we need a rule for the application. Under Security Rules click on Create Security Rule.


Here, chose Minecraft as the Security Application and 'public internet' as Source Security List.

Now the Minecraft rule is shown under the SSH Rule.


Start Minecraft and configure a new Server. Give it a name and enter the public IP address of your instance.


Your Oracle Cloud instance will be listed in Minecrafts server list, notice the good ping. Double click to start your game.


Have fun with the Oracle Cloud and Minecraft!

Tuesday, 22 September 2015

Oracle Managed File Transfer (MFT) Handson - Part 4: Integration with SOA Suite

[Part 1] [Part 2] [Part 3] [Part 4] 

For users of both, MFT and SOA-Suite, both can be integrated. The SOA Suite can push data to MFT, which takes care of distributing those in the file system. And vice versa, the SOA Suite can be a target for a MFT transaction.
For this example, both MFT and SOA Suite should be installed. Basic knowledge of both products is required.


Starting with the Design tab of the MFT Console. A new source of type SOA is created here. Important: don't chose the name soa as depicted above, as this will lead to problems later. So chose a different name like service-source.


Next, a Transfer needs to be created, using the newly created service-source as Source. Create any File Target as target for this transformation, eg. the file-target from chapter 3.
Then click Save and Deploy, so both artifacts are deployed.


Next, open JDeveloper and create a new SOA-Project.


In the composite, drop a MFT adapter to the right side.


Accept the defaults


Also keep the defaults here


In this step, an existing application server connection can be chosen or a new one be created. The MFT server in that domain will be found automatically, click on Test MFT to check the connection.


The serivce-source will be found automaticall, end this wizard with Finish.


To have something to communicate with the MFT adapter, drop a BPEL process into the composite. In the dialog shown above, switch it to Synchronous BPEL Process and leave the rest.


Connect the MFT adapter with the BPEL process, then open the process with a double click.


Place an Invoke activity in the middle and connect it with the MFT partner link.


Create an input- and output-variable by clicking on each green plus sign (+). Then close the dialog with OK.


An assign activity is needed, place it before the Invoke1 and open it via double click.


Right click on ns1:InlinePayload to assign an expression.


Create a greeting, eg. one matching the region you live in. In my case:
concat("Moin, Moin ", $inputVariable.payload/client:input)


Do the same for ns1:TargetFilename. As this is the name for the target file, better avoid special characters which could cause troubles on some file systems. Eg.:
concat("Hello-",$inputVariable.payload/client:input)

The composite is ready now and need to be deployed (right click on [project name]|Deploy).
Next, open the Enterprise Manager and navigate to that project. Go to the Test Web Service page, enter a test string and start the test.


If everything was OK, the Flow Trace can be launched.


The flow trace will contain a MFT step, click on it.


This will lead to the MFT Console where the Transfer will be displayed.


In the file system, the resulting will be created. Open it and check the contents.

That's the end of the MFT tutorial

[Part 1] [Part 2] [Part 3] [Teil 4]

Thursday, 28 May 2015

Oracle Managed Files handson tutorial part 3: Custom Callouts

[Part 1] [Part 2] [Part 3] [Part 4]

The built-in functionality from MFT can be extended with custom code via Custom Callouts in Java.
Three things are necessary: the Java code itself, an xml file which describes what MFT should do with this code and a WST call to register that code to MFT.
The complete documentation can be found on OTN, this tutorial should demonstrate the creation and integration of Custom Callouts with a very simple example.
In this example, a Custom Callout will be developed, which replaces the file name with the actual system time.
For stepping through this tutorial, it should be known, how to create and compile a Java class and Part 1 of this tutorial should be completed.
Here is the Java code:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
package com.oracle.callout.sample;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
import java.util.Map;
import java.util.Date;

import oracle.tip.mft.engine.processsor.plugin.PluginContext;
import oracle.tip.mft.engine.processsor.plugin.PluginOutput;
import oracle.tip.mft.engine.processsor.plugin.PreCalloutPlugin;


public class FilenameCallout implements PreCalloutPlugin {

 @Override
 public boolean isPayloadChangeRequired(PluginContext context,
   Map<String, String> calloutParams) {
  return false;
 }

 @Override
 public PluginOutput process(PluginContext context, InputStream input,
   OutputStream out, Map<String, String> calloutParams) {
  String type = calloutParams.get("Type");

  return null;
 }

 @Override
 public PluginOutput process(PluginContext context, InputStream input,
   Map<String, String> calloutParams) {

  PluginOutput pOutput = new PluginOutput();
  pOutput.setNewFileName("MFT " + new Date() );
  return pOutput;
 }
}

All imports, except java.util.Date are required by every Custom Callout.
The method isPayloadChangeRequired() gives MFT a hint, whether the payload will be changed or not - as the name implies. Depending on that, either of the following methods will be called. As in this example only the file name, but not the content, will be changed, isPayloadChangeRequired() returns false. The first process method is not needed and just returns null. Only the second process method will be called during runtime and does something. It changes the file name.

[oracle@oel6ab src]$ javac -classpath "/home/oracle/Oracle/Middleware/soa12103/mft/modules/oracle.mft_12.1.3.0/core-12.1.1.0.jar" com/oracle/callout/sample/FilenameCallout.java 
[oracle@oel6ab src]$ jar cf FilenameCallout.jar com/oracle/callout/sample/FilenameCallout.class 
[oracle@oel6ab src]$ ll
total 12
drwxr-xr-x. 3 oracle oinstall 4096 Feb  6 15:23 com
-rw-r--r--. 1 oracle oinstall 1187 Feb  9 16:42 FilenameCallout.jar

The class has to be compiles as shown above, the path names need to be adapted to your environment. As a result, we get a FilenameCallout.jar file and we are done with the Java part.
In the next step, an XML file will be created, so MFT knows what to do with this JAR file.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
<?xml version="1.0" encoding="UTF-8"?>
<mft:Callouts xmlns:mft="http://xmlns.oracle.com/mft" 
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
 xsi:schemaLocation="http://xmlns.oracle.com/mft callout.xsd ">
 <mft:Callout description="Filename conversion"
  helpText="File name conversion"
  groupName="Source-pre,Target-pre,Target-post" 
  timeout="300" 
  implementationClass="com.oracle.callout.sample.FilenameCallout"
  libraryName="FilenameCallout.jar" 
  name="Filename conversion">
 </mft:Callout>
</mft:Callouts>

The XML file is very straight forward. Important is the name, which has to be unique in a MFT instance. The attributes libraryName and implementationClass are self explanatory (hopefully ;-).

Both files needed to be copied into the mft directory of the WLS domain. If the subfolder callouts doesn't already exist, it needs to be created manually. Then FilenameCallout.jar and FilenameCallout.xml have to be copied into the callouts-folder.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
CLASSPATH=:/home/oracle/Oracle/Middleware/soa12103/mft/modules/oracle.mft_12.1.3.0/core-12.1.1.0.jar

Initializing WebLogic Scripting Tool (WLST) ...

Welcome to WebLogic Server Administration Scripting Shell

Type help() for help on available commands

wls:/offline> connect("weblogic","welcome1","t3://localhost:7003")
Connecting to t3://localhost:7003 with userid weblogic ...
Successfully connected to managed Server "mft_server1" that belongs to domain "soa_domain".

Warning: An insecure protocol was used to connect to the 
server. To ensure on-the-wire security, the SSL port or 
Admin port should be used instead.

wls:/soa_domain/serverConfig> crtCalls("/home/oracle/Oracle/Middleware/soa12103/user_projects/domains/soa_domain/mft/callouts/FilenameCallout.xml")
Callout Filename conversion created.

wls:/soa_domain/serverConfig> listCallouts() 
Callouts
-----------
[Name:Filename conversion, Library:FilenameCallout.jar, Impl Class:com.oracle.callout.sample.FilenameCallout, Description:Filename conversion, Group:Source-pre,Target-pre,Target-post]
wls:/soa_domain/serverConfig> 

To inform MFT about the new callout, WLST will be used. For using the MFT specific commandos, the wlst.sh has to be started from the MFT directory under $MW_HOME/mft/common/bin. The first line of the output with the CLASSPATH shows, if the correct script has been used.
As always with WLST, first connect to the server. Then the callout will be registered by a crtCalls(...) call with the XML file as a parameter.
All registered callouts can be shown via listCallouts() and they can be deleted by deleteCallout(...).
Again, two directories for source and target are needed. This could be the ones from the first part of this tutorial, or just create new ones.
In the MFT Console, both directories are configured as source and target, as shown in part 1.
Then, a Transfer will be configured using both directories.
After clicking at <add pre-processing actions>, the new choice 'Filename conversion' can be added via the Add to List Button.

The result should look as shown above. Click on Save, then finish with Deploy.

After a short period of time, the successfull Transfer should be shown on the dashboard.
Also, the transferred file with the changed name should appear in the file system. That's it for the MFT Custom Callouts handson tutorial. The next part will explain the integration with the Oracle SOA Suite.

--> Next: Integration with SOA Suite

[Part 1] [Part 2] [Teil 3] [Part 4]