Up to Jenkins 1.460, its Subversion plugin 1.39 hasn't supported Subversion 1.7, so you may hit error like below screen shot :
Instead of waiting for the plugin to be updated, there is a workaround :
1. Install the latest CollabNet Subversion Client to the server, which provides svn command-line tool.
2. Put all maven commands into a shell, i.e. bat for Windows.
3. Use maven-antrun-plugin to execute that shell.
4. In Jenkins configuration page, just use 'antrun:run' as the 'Goals and options'.
It works because the shell will use the system variable where PATH includes the latest CollabNet path rather than the old svn path used by Jenkins.
Projects using XMPP server/client may encounter an issue that XMPP server will kill client connection if it's idle for some time. Of course, you can set it to never disconnect client but it puts another problem on board which is messages will be lost if client gets offline irregularly. XMPP server caches offline message only when the client status shows offline on server side. That's why in most of cases people will choose to set an idle time for client to be killed so that messages sent after disconnection of client will be queued in server side. However, how long the idle time should be set is still a case by case skill, which is actually out of the topic in this article.
What I'm going to showcase today is how to implement XMPP Pong on client side answering to XMPP Ping sent from server side to keep client alive when idle time is set. As you can see, XMPP Ping is the way the XMPP server is used to detect whether client is still alive or not, so according to XMPP Protocol
, two options you have to respond XMPP Ping : a) Pong b) Pong not supported.
As not every XMPP client library supports XMPP Pong, i.e. Smack API 3.0.0.beta1, below sample implementation is provided based on the 2nd comment in this discussion
1) Create class Ping extends IQ implements IQProvider
2) Create PingProvider
3) Create PingPacketFilter to filter out XMPP Ping sent from server side.
4) Create Pong based on the protocol
. In this case, we choose 'b' option which is to implement 'Pong not supported'.
5) Create PingPacketListener to answer XMPP Ping
6) Client responds to the server
At this point of time, you should be able to see the IllegalArgumentException thrown on server side, i.e. OpenFire, as below shown :
This exception is designed and acceptable according to the protocol, so it should good enough to keep client connection alive.
On 3rd of October 2011, Apple announce its Mobile Device Management(MDM) reference available on iOS provisioning portal. However, the sample code in the reference is fragmentary, especially on 'MDM Vendor CSR Signing Overview' section, which is to generate pList.
Softhinker works out below guidline to facilitate developers on pList generating process :
- There are two roles involved in the entire process : vendor
- As a vendor,
- create a CSR using any toolkit, i.e. KeyChain Access on MacBook, then export private key as 'vendor.p12'
- select 'Certificates' on the left navigation bar, and click 'Other' tab on the center.
- follow the instruction on that page, and upload the CSR you created.
- then the certificate for you as a MDM vendor will be available to download on the 'Other' tab. And download it.
- execute below openssl command to convert MDM vendor certificate, WWDR certificate, and Apple root certificate to PEM format one by one :
openssl x509 -inform der -in mdm_identity.cer -out mdm.pem
openssl x509 -inform der -in AppleWWDRCA.cer -out intermediate.pem
openssl x509 -inform der -in AppleIncRootCertificate.cer -out root.pem
- As a customer,
- create a CSR using any toolkit, i.e. openssl :
openssl genrsa -des3 -out customerPrivateKey.pem 2048
openssl req -new -key customerPrivateKey.pem -out customer.csr
- convert customer.csr to der format :
- Then use the attached Java program to generate encoded plist, and upload to https://identity.apple.com/pushcert/
openssl req -inform pem -outform der -in customer.csr -out customer.der
- remember to replace the placeholder in the package with your own ones :
- please note that generated plist.xml is not the one to upload, plist_encoded is.
customer.der, vendor.p12, mdm.pem, intermediate.pem, root.pem
Currently, iOS MDM Push Cert portal has a problem so that all plist uploaded will get a 'Invalid Certificate Signing Request', and a fix is supposed to be installed on January 2012.
Please like or +1 if you find it helpful. Thanks!
This is the final post of this Series.
10. Google Apps helps reduce the risk of data breaches
The use of laptops, smartphones, tablets and other mobile devices increases the risk of data breach if you're using traditional application which stores a local copy of your data, especially when mobile devices get lost or stolen, like what happened to Hong Kong star Edison Chen.
Google Apps can help reduce the risk of a data breach by limiting the data that is stored on your devices. When you check email or work on a document in a browser with Google Apps, the data is stored in our data centers, not on your device. That means that if your device gets lost or stolen, there is lower overall risk of a data breach. Similarly, if you collaborate with others in Google Docs, you don’t need to send them a copy of the document. You can enable and disable access to the document with a simple set of sharing controls and your collaborators access it from their browser. The document does not need to be stored locally on their device for them to collaborate on it.
For those times when you want to access Google Apps but you don’t have an Internet connection, we recently released an offline capability for Gmail and for Google Docs. The offline capability does involve some local data storage on devices. The amount of stored data is likely to be smaller as only a limited amount of documents and email are synchronized to the device for offline access. If you decide that this local data storage poses a risk, you can easily disable offline access.
As a Google Apps Authorized Reseller, Softhinker hopes you gain confidence on Google Apps solution through this series of posts, and we'd like to hear from you for further discussion.
7. Google Apps data protections - verified by third parties
In such a world where Cloud Computing is being talked everywhere, how do you distinguish who is the trusted Cloud Computing provider?
Cloud computing companies use the the SSAE 16
Type II audit, and its international counterpart ISAE 3402
Type II audit, to document and verify the data protections in place for their services. These auditing standards are defined by the The American Institute of Certified Public Accountants (AICPA) and the the International Auditing and Assurance Standards Board (IAASB), respectively. These audit standards have replaced the SAS 70 Type II audit, which Google Apps first completed in 2008
. In Google's audits, they specify the confidentiality, integrity and availability controls that our customers are most concerned about, which are then verified by our auditors. Google recently announced that they’ve successfully completed the SSAE 16 and ISAE 3402 Type II
audits for Google Apps, Postini services, Google Apps Script, Google Storage for Developers and Google App Engine.
Google Apps for Government has also received Federal Information Security Management Act (FISMA)
certification from the U.S. Government. The FISMA certification includes a rigorous evaluation of the security processes and data protections in place in Google Apps for Government and is required by U.S. federal government customers, who must comply with FISMA by law.
Just $5/user/month will enhance your business with edge technology powered by Google, and Softhinker
provides a hassle-free service to help your company equiped with excellent Google Apps!
6. New apps status dashboard improves visibility
Do you know what's the best merit of Google products I like? Open.
Merely sharing source codes to the world is not open in my dictionary. Google shares more than that. App status is one of what Google opens to the world, no matter the status is good or bad, though which users know how long is the downtime for Gmail recently, or was there a disruption or outrage for Google Sites?
Please don't regard this innovation as redundant or insignificant, especially when you're choosing which service/product is worth to invest. The best evidence is the statistics of its history, isn't it? Then how many service providers out there dare to provide the real app status to all of the world? Many of them just want to polish a beautiful financial report to the stock holders, rather than tell the truth. Google has the confidence to its technology, so it's open.
Let's take a look at some real data to gain more feeling. Last year, Gmail was up and running 99.984% of the time, and in the first half of 2011 Google has delivered 99.99% availability—that’s less than 5 minutes of downtime, on average, per month. A new App Status Dashboard
gives you accurate information faster, which can be used to evaluate Google products before investing on it.
Once your confidence is established, please drop us an email
, and Softhinker
would like to bring amazing Google Apps solutions to your organization!
5. Disaster recovery - built right in to Google Apps
Disaster recovery of business data is, to some belief, a topic that only big company should consider, while oppositely I totally disagree with this point of view.
To some extent, those giat companies are so robust that it's contrastively easy to recover from the critical data lost. Well, how about small/medium enterprises? Can SMEs afford data disaster? Maybe just one time of data lost is enough to kill a start-up business, isn't it?
So to my opinion, it's equally important for both big boys and small players in terms of disaster recovery.
Then question is how to establish a trusted and cost-effective disaster recovery plan?
The effectiveness of a disaster recovery plan is commonly measured in two ways: Recovery Time Objective (RTO) and Recovery Point Objective (RPO). RTO measures how long before users can access systems in the event of a failure. RPO measures how much of a time gap exists when the data is restored. Businesses that have invested lots of time and money in disaster recovery preparation are typically able to set RTO and RPO goals at a few hours or less for critical systems, with the cost increasing as those timeframes decrease. For other businesses that haven’t invested at that level, RTO and RPO can stretch into hours or days. And in extreme cases, if disaster strikes, some businesses just have to start over.
Google Apps offers a better way, with robust disaster recovery capabilities built right in. Our RPO design target is zero data loss and our RTO design target is instant failover. This means that if there is a disaster or disruption that affects one of our data centers, we are able to shift users to an alternate data center, so they can can continue working uninterrupted. And while no disaster recovery solution from any provider is perfect, Google is proud of the benefits customers gain.
The most attractive part of how to leverage on this excellent solution is : drop softhinker
an email today!
Please answer this question before reading through : are you using the same password for different website account log in?
If yes, it'll be risky especially when you create account in some website who may use the same password to try your account in other website. This happens frequently in currently popular mobile apps. For example, some one create a mobile app who declares that it can help you log in to your Facebook, Twitter, LinkedIn, etc. in one go. Familiar with this kind of apps? Then how do you know it will not remember and send your password to their own server for other purposes?
To some extent, it's still ok if the account is your personal one. But what if it's your business account?
Now, Google provides 2-factor authentication
to drastically reduce the chance of having your account stolen by someone else. Simply speaking, other than username and password, there will be a one-time code randomly generated and send to your phone by SMS or Voice call after you log in, then you just need to key in what you get to gain access to your valuable account. This 2-factor authentication is frequently used in online banking system, and now Google applies it in all Google accounts. If your mobile device cannot receive text message or voice call, i.e. tablet, an app called Google Authenticator
provided by Google can also help you get the one-time code immediately even without internet! Is that cool? Enable it in the account page
Well, what's more for Google Apps for Business account? Of course it provides stronger protection and convenience! For businesses that already use separate authentication and would like to continue using them, Google Apps for Business provides SAML(Security Assertion Markup Language)-based SSO(Single Sign On) to do this. This technology also allow business to apply custom security features, password management policies, and their own 2-factor authentication solution. So, this SSO capability is an alternative to the standard 2-factor authentication that is included in normal Google Apps if you think it's not secure enough for your business.
如果是的话，这将存在这样的风险：某些网站可能用你的密码来尝试登录其他的网站。这个经常发生在当前很流行的手机软件中。比如，某手机软件提供这样的功能——宣称可以帮你同时登录Facebook, Twitter, LinkedIn等等。很熟悉这样的软件对吗？那么你怎么知道它不会记录你的密码并发送到他们自己的服务器上另作他用呢？
那么，对于Google Apps企业版来说还有什么更多的功能吗？当然！对于那些已经在使用另外的验证方式并且想继续使用它的公司来说，Google Apps企业版提供了基于SAML（Security Assertion Markup Language）的单点登录（Single Sign On）来实现。这种科技允许企业应用自定义的安全功能、密码管理策略、和他们自己的“双因子验证”。所以，这是一种替代Google Apps提供的常规安全验证机制的选择如果你觉得常规安全验证机制对于你的商业来说不够安全的话。