DOCSLIB.ORG

Cernbox + EOS: Cloud Storage for Science

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Cernbox + EOS: Cloud Storage for Science Data & Storage Services CERNBox + EOS: Cloud Storage for Science Presenter: Luca Masce Thanks to: Jakub T. Mościcki, Andreas J. Peters, Hugo G. Labrador, Massimo Lamanna CERN/IT-DSS CERN IT Department CH-1211 Geneva 23 Switzerland www.cern.ch/it Content • What we have done • What we do • What we will do CERNBox 2 The origins of the CERNBox project • Missing link? CERNBox • 4500 disSnct IPs in DNS from cern.ch to *.dropbox.com (daily...) • What we are missing • easy access “cloud storage for end users” • files go ‘automacally’ to the cloud and are available ‘always everywhere’ • broken laptop ≠ data lost • offline access to data • work on the plane and rsync when back online • keep files in sync across devices • access on mobile clients • (easy) sharing of files with colleagues • sSll surprisingly difficult • Can we have this? • for “documents” (small files, oben ppts, text,…) • for “science data” (integrated into data processing workflows and exisSng infrastructure) 3 Original architecture (CERNBox beta service) Sync client (webdav) Data flow HTTPS Metadata flow LB Web access (hgps) Apache, PHP 5.4 (SCL1.0) mod_proxy_balancer USER 64 core, 64GB RAM AS OC AS OC AS OC • Setup 100% RH6 on “standard” hardware • Based on ownCloud • Guaranteed failover (redundant nodes) SQL overheads filesystem (Hz metadata ops) (POSIX) Keeps track of Files not exposed sync state directly to the user for every STORAGE file in DB Image courtesy of the system MySQL server NFS servers, async, SW RAID 1 www.phdcomics.com 48GB RAM IniSal space: 20 TB Usage of the beta service CERNBox March April May June … October Beta 2014 users 190 (*) 285 361 429 720 files 191K 907K 1.6M 2.7M 6.4M size 480GB 1TB 1.5TB 1.9TB 3.4TB (*) users inherited from the iniSal prototype deployment Size per user Files per user 1% Avg ~5GB 5% Avg ~10K files 1% 15% <10GB < 5K >10GB 5K-20K up to 100GB up to 100K 84% 94% 5 File access patterns • GET/PUT rao: 2/1 • File type distribuSon: • 1200 different file extensions! • 30% .c .h .C • 30% .jpg .png • 15% no extension (UNIX world!) • 25% other: .pdf, .txt, .ppt, .docx, .root, .py, .eps, .tex • ~100 URL shares, ~40 synced shares • UNICODE filenames: greek, russian, thai(?) 6 Pilot limitations • Move • On the origin client move is propagated to the server • On the other clients it is propagated as COPY/DELETE (subopSmal) • Symlinks are not supported • Ignored files: , : ? * “ < > | • We currently recommend one sync folder setup: ~/cernbox • High per-file overhead • Expect 2-5Hz PUT • Expect ~10Hz GET • Transfer rates • Expect 10-30MB download • Expect 5-10MB upload • Larger files: 400MB file on standard desktop • hgps/upload: ~25MB/s, hgps/download: ~60MB/s • For wireless devices, laptops, phones… do we care about transfer rates? 7 Towards large-scale data sync and share • Currently deployed CERNBox beta • works OK so far for the classical Dropbox use-case • low-frequency document sync and share • But can we bring this system to the next level? • Our core-business and large-scale workloads • expose PBs of exis%ng data from day 1 • integraon into physics data processing eco-system • central services: batch, interacSve • data analysis applicaons • sync higher data volumes at higher rates • Can we sSll keep the simplicity of cloud storage access? 8 Massive scaling at reduced cost? • No need to keep track of all files and directories in the database • avoids explosive growth of your DB infrastructure • Our file number esSmate? With 10K users we have 2.5 billion files in AFS already! • What is your number for 100K users? • Before we start throwing hardware at the problem… … consider the cost of running the service • Fixed: hardware purchase, service deployment, infrastructure • Scaling: hardware incidents, user support; backup; integrity checks; upgrades • Infrastructure: space, electricity and cooling in the data center • For massive scaling we need to keep TCO under control • profit from exisSng large-scale operaons and support of our storage services • exploit economies of scale 9 Integration • Started in May 2014 • FuncSonality • Enable sync and share for exisSng data in EOS • Without exporSng data to another storage • Direct access to data with efficient sync behind • Operaons • NFS/async backend server is a temporary soluSon • EOS offer “virtually unlimited” cloud storage for end-users • Fold-in the operaon cost into EOS… • But: • Integrate as transparently as possible • most users don’t care about storage backend • Fully working soluSon compable with owncloud clients • we don’t want to end up with half-working CERN-specific soluSon 10 EOS Integration Details • Understanding sync protocol and underlying semanScs. • Add a few consistency features to EOS (e.g. atomic upload) • Adding few new features to EOS or libing restricSons (e.g. UTF8 support) • Beef-up the webdav endpoint to allow owncloud clients to talk directly to it • Integrate web-access and sharing funcSonality • Web fronted: develop new plugins • Nice integraon of trashbin, versions and sharing: • Fusion between owncloud model and EOS model (Hugo G. Labrador) • Making more robust less stressed parts in EOS (hgp/webdav) • Lots, lots of tesSng. 11 CERNBox 2.0 Architecture Data flow Metadata flow Sync client (webdav) HTTPS HTTPS HTTPS LB LB HTTPS Web access (hgps) LB LB Data directly hgps (private data) accessible USER OC by the user hgp (internal) hgp (public data) KHz fuse metadata ops All sync state STORAGE (EOS) as metadata in the storage IO redirect Files wriYen with USER credenZals disk servers (1000s) namespace Prototype deployment on EOSPPS • /eos/user/<u>/<username> • this is the default sync and web-enabled folder • …as an advanced user you may add arbitrary folder from EOS • very easy to implement a folder shared by an e-group • We can also allow transparent access to different instances 13 First performance numbers • User-perceived performance (client) • Metadata operaon (pycurl with SSL sessions) • PROPFIND with 1 entry: 90 Hz • PROPFIND with 1K entries: 8.5 KHz • PROPFIND with 10K entries: 10KHz • nice speed e.g. • kernel src tree upload (50K files, 500MB) ~ 1h from laptop/wifi at home, download ~20 min ops/s 200 200 Small files (10KB) pycurl seq 150 125 pycurl P=10 100 70 60 65 50 57 pycurl P=50 30 30 50 20 11 owncloud sync client 0 Download Upload Delete 14 Summary • Working and usable beta service • Useful for geng experience, user feedback and understanding what we want / don’t want in the final producSon system based on EOS CERNBox • Advanced integraon into EOS will open up new possibiliSes • but there is no free lunch: we will have to adapt to evolving owncloud clients, etc…. • heading towards large sync and share layer for science research • all our data exposed from day 1 • massive scalability, high performance • integrated into exisSng workflows - new capabiliSes! • small overhead on top of our exisSng operaons and development • TCO control • …and sSll as easy to use as Dropbox.com… 15 Integrated storage ecosystem for scientific research 2.0 sync / share / offline access webdav & hps:// CERNBox USER online file-system access fuse Analysis cluster high-performance applicaon access LARGE-SCALE xrootd:// STORAGE Central Services batch access xrdcopy • agenda full • ~35 parScipants • Tracks • Keynote • B.Pierce • Technology • Users • Site reports • Vendor talks • IBM • Powerfolder • SeaFile • PyDio • Owncloud 17 CERNBox 2.0 – some numbers • Advanced prototype stage • Adapted exisSng webdav interface in EOS to be compable with owncloud sync clients • Test environment (EOSPPS) • standard hardware • namespace node with Xeon 2.2GHz, 16 cores, 24GB RAM • 50 disk servers: cheap JBODs (1000 disks), total 800TB usable space • Storage layout: 2 replicas in RAIN mode • à every file PUT = 2 copies of the file on two independent storage nodes (with adler32 checksums of content) • Event-based hgp(s) load-balancer (nginx) • Underlying storage scalability (EOS Prod) • Max observed IO: ~40GB/s on a single instance (eosatlas => ) • Max observed file stats: 10s KHz • Thousands of connected clients • Server should never be a bogleneck for CERNBox… 18 .
Load more

Recommended publications
  • Cryptomator Documentation Release 1.5.0
    Cryptomator Documentation Release 1.5.0 Cryptobot Sep 15, 2021 Desktop 1 Setup 3 1.1 Windows...............................................3 1.2 macOS................................................3 1.3 Linux.................................................3 2 Getting Started 5 3 Adding Vaults 7 3.1 Create a New Vault..........................................8 3.2 Open an Existing Vault........................................ 13 4 Accessing Vaults 15 4.1 Unlocking a Vault.......................................... 16 4.2 Working with the Unlocked Vault.................................. 17 4.3 Locking a vault............................................ 18 5 Password And Recovery Key 21 5.1 Change Password........................................... 21 5.2 Show Recovery Key......................................... 22 5.3 Reset Password............................................ 23 6 Vault Mounting 27 6.1 General Adapter Selection...................................... 27 6.2 Options applicable to all Systems and Adapters........................... 27 6.3 WebDAV-specific options...................................... 28 6.4 Dokany-specific options....................................... 28 6.5 FUSE-specific options........................................ 28 7 Vault Management 29 7.1 Remove Vaults............................................ 29 7.2 Reorder Vaults............................................ 29 7.3 Vault Options............................................. 29 8 Setup 33 8.1 Google PlayStore..........................................
    [Show full text]
  • Towards Web-Based Delta Synchronization for Cloud Storage Services
    Towards Web-based Delta Synchronization for Cloud Storage Services He Xiao Zhenhua Li ∗ Ennan Zhai Tianyin Xu Tsinghua University Tsinghua University Yale University UIUC Yang Li Yunhao Liu Quanlu Zhang Yao Liu Tsinghua University Tsinghua University Microsoft Research SUNY Binghamton Abstract savings in the presence of users’ file edits [29, 39, 40]. Delta synchronization (sync) is crucial for network-level Unfortunately, today delta sync is only available for efficiency of cloud storage services. Practical delta sync PC clients and mobile apps, but not for the web—the most pervasive and OS-independent access method [37]. techniques are, however, only available for PC clients 0 and mobile apps, but not web browsers—the most per- After a file f is edited into a new version f by users, vasive and OS-independent access method. To under- Dropbox’s PC client will apply delta sync to automati- stand the obstacles of web-based delta sync, we imple- cally upload only the altered bits to the cloud; in contrast, Dropbox’s web interface requires users to manually up- ment a delta sync solution, WebRsync, using state-of- 0 1 the-art web techniques based on rsync, the de facto delta load the entire content of f to the cloud. This gap sig- sync protocol for PC clients. Our measurements show nificantly affects web-based user experiences in terms of that WebRsync severely suffers from the inefficiency of both sync speed and traffic cost. JavaScript execution inside web browsers, thus leading Web is a fairly popular access method for cloud stor- to frequent stagnation and even hanging.
    [Show full text]
  • Cheat Sheet – Common Ports (PDF)
    COMMON PORTS packetlife.net TCP/UDP Port Numbers 7 Echo 554 RTSP 2745 Bagle.H 6891-6901 Windows Live 19 Chargen 546-547 DHCPv6 2967 Symantec AV 6970 Quicktime 20-21 FTP 560 rmonitor 3050 Interbase DB 7212 GhostSurf 22 SSH/SCP 563 NNTP over SSL 3074 XBOX Live 7648-7649 CU-SeeMe 23 Telnet 587 SMTP 3124 HTTP Proxy 8000 Internet Radio 25 SMTP 591 FileMaker 3127 MyDoom 8080 HTTP Proxy 42 WINS Replication 593 Microsoft DCOM 3128 HTTP Proxy 8086-8087 Kaspersky AV 43 WHOIS 631 Internet Printing 3222 GLBP 8118 Privoxy 49 TACACS 636 LDAP over SSL 3260 iSCSI Target 8200 VMware Server 53 DNS 639 MSDP (PIM) 3306 MySQL 8500 Adobe ColdFusion 67-68 DHCP/BOOTP 646 LDP (MPLS) 3389 Terminal Server 8767 TeamSpeak 69 TFTP 691 MS Exchange 3689 iTunes 8866 Bagle.B 70 Gopher 860 iSCSI 3690 Subversion 9100 HP JetDirect 79 Finger 873 rsync 3724 World of Warcraft 9101-9103 Bacula 80 HTTP 902 VMware Server 3784-3785 Ventrilo 9119 MXit 88 Kerberos 989-990 FTP over SSL 4333 mSQL 9800 WebDAV 102 MS Exchange 993 IMAP4 over SSL 4444 Blaster 9898 Dabber 110 POP3 995 POP3 over SSL 4664 Google Desktop 9988 Rbot/Spybot 113 Ident 1025 Microsoft RPC 4672 eMule 9999 Urchin 119 NNTP (Usenet) 1026-1029 Windows Messenger 4899 Radmin 10000 Webmin 123 NTP 1080 SOCKS Proxy 5000 UPnP 10000 BackupExec 135 Microsoft RPC 1080 MyDoom 5001 Slingbox 10113-10116 NetIQ 137-139 NetBIOS 1194 OpenVPN 5001 iperf 11371 OpenPGP 143 IMAP4 1214 Kazaa 5004-5005 RTP 12035-12036 Second Life 161-162 SNMP 1241 Nessus 5050 Yahoo! Messenger 12345 NetBus 177 XDMCP 1311 Dell OpenManage 5060 SIP 13720-13721
    [Show full text]
  • Diplomarbeit Kalenderstandards Im Internet
    Diplomarbeit Kalenderstandards im Internet Eingereicht von Reinhard Fischer Studienkennzahl J151 Matrikelnummer: 9852961 Diplomarbeit am Institut für Informationswirtschaft WIRTSCHAFTSUNIVERSITÄT WIEN Studienrichtung: Betriebswirtschaft Begutachter: Prof. DDr. Arno Scharl Betreuender Assistent: Dipl.-Ing. Mag. Dr. Albert Weichselbraun Wien, 20. August 2007 ii Inhaltsverzeichnis Abbildungsverzeichnis vi Abkürzungsverzeichnis vii 1 Einleitung 1 1.1 Problemstellung . 1 1.2 Inhalt und Vorgehensweise . 3 2 Standards für Kalender im Internet 5 2.1 iCalendar und darauf basierende Standards . 6 2.1.1 iCalendar und vCalendar . 6 2.1.2 Transport-Independent Interoperability Protocol (iTIP) . 8 2.1.3 iCalendar Message-Based Interoperability Protocol (iMIP) . 8 2.1.4 iCalendar über WebDAV (WebCAL) . 10 2.1.5 Storage of Groupware Objects in WebDAV (GroupDAV) . 11 2.1.6 Calendaring and Scheduling Extensions to WebDAV (CalDAV) . 12 2.1.7 IETF Calendar Access Protocol (CAP) . 13 2.2 XML-basierte Formate . 15 2.2.1 XML iCalendar (xCal) . 15 2.2.2 RDF Calendar (RDFiCal) . 16 2.2.3 RDFa (RDF/A) . 16 2.2.4 OWL-Time . 17 2.3 Mikroformate (hCalendar) . 18 2.4 SyncML . 20 2.5 Weitere Formate . 21 2.6 Zusammenfassung . 22 iii 3 Offene Kalenderanwendungen im Internet 24 3.1 Server . 24 3.1.1 Citadel/UX . 24 3.1.2 Open-Xchange . 26 3.1.3 OpenGroupware.org . 26 3.1.4 Kolab2 . 27 3.1.5 Weitere Server . 28 3.2 Clients . 29 3.2.1 Mozilla Calendar Project . 29 3.2.2 KDE Kontact . 30 3.2.3 Novell Evolution . 30 3.2.4 OSAF Chandler . 31 3.2.5 Weitere Open-Source- und Closed-Source-Clients .
    [Show full text]
  • Genesys Interaction Recording Solution Guide
    Genesys Interaction Recording Solution Guide Configuring WebDAV 9/27/2021 Contents • 1 Configuring WebDAV • 1.1 Deploying the WebDAV Server • 1.2 Configuring TLS for the WebDAV Server • 1.3 Changing storage location • 1.4 Next Step Genesys Interaction Recording Solution Guide 2 Configuring WebDAV Configuring WebDAV Interaction Recording Web Services relies on a Web Distributed Authoring and Versioning (WebDAV) server to store and manage the GIR recording files. WebDAV is an extension of the Hypertext Transfer Protocol (HTTP) that facilitates collaboration between users in editing and managing documents and files stored on World Wide Web servers. A working group of the Internet Engineering Task Force (IETF) defined WebDAV in RFC 4918. The following information represents examples of what can be done for WebDAV. Follow these procedures to get a better understanding of what needs to be done when you use a Red Hat Enterprise Linux machine with the Apache HTTP Server. Important • This document provides you with basic guidelines on configuring WebDAV on RHEL. If you wish to configure WebDAV on other operating systems or if you have additional questions regarding WebDAV on RHEL, refer to the official documentation from the operating system provider. • It is recommended that you do not install WebDAV on the same machine as Interaction Recording Web Services (RWS), since numerous deployments already install Cassandra and Elasticsearch on the same host. These are critical components for the operation of RWS. If an additional process such as WebDAV is run on the same machine as RWS, disk I/O operations will be limited and the stability of RWS may be negatively impacted.
    [Show full text]
  • 8144 CMU Updates: 7240 April 2017 Category: Standards Track ISSN: 2070-1721
    Internet Engineering Task Force (IETF) K. Murchison Request for Comments: 8144 CMU Updates: 7240 April 2017 Category: Standards Track ISSN: 2070-1721 Use of the Prefer Header Field in Web Distributed Authoring and Versioning (WebDAV) Abstract This document defines how the Prefer header field (RFC 7240) can be used by a Web Distributed Authoring and Versioning (WebDAV) client to request that certain behaviors be employed by a server while constructing a response to a request. Furthermore, it defines the new "depth-noroot" preference. This document updates RFC 7240. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8144. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
    [Show full text]
  • Hornet.Email Fact Sheet
    HORNET.EMAIL Do not compromise: Combine Microsoft 365 with cost-effective mailboxes within your existing domain or use Hornet.email as a stand alone solution. Hornet.email: The cloud-based corporate communications platform with the market’s most efficient filter for protection against spam and malware directly integrated. The email and collaboration environment, consisting of mailbox, calendar and address book, offers users maximum protection against spam, phishing and other cyber threats based on multiple layers of security and AI-based analysis. The market’s highest guaranteed spam and virus detection rates protect users not only from annoying email flooding, but also from infection by ransomware or spyware. BENEFITS OF HORNET.EMAIL: Z• Easy, fast onboarding Z• Can be combined with M365 • Z Central control • Z Synchronization on all devices • Z Hosting in german data centers EXAMPLE OF HORNET.EMAIL INTEGRATION IN THE EMAIL MANAGEMENT SYSTEM Sender / Hornetsecurity Customer Recipient Hornet.email Spam and Smartphone, Malware Tablet, Desktop Mail- Protection server ATP (optional) Archiving with: M365 Outlook Thunderbird Native Client (optional) www.hornetsecurity.com I [email protected] RELIABLE FEATURES AND EFFICIENT ANALYSIS MECHANISMS FOR SECURE CORPORATE COMMUNICATIONS: Synchronization across all devices: Hornet.email can be accessed via a web interface, native clients or Outlook clients from all common modern PCs (Windows, Mac, Linux) and mobile devices (iOS, Android). Users can access not only all their emails, but also their calendar and tasks - simply, securely and without compromise. Collaborative compatibility: Hornet.email supports various calendar and task formats such as WebDAV, CalDAV, Card- DAVWebDav, Webcal and ical. Guaranteed availability: The average annual availability of email using SMTP and Hornet.email interfaces and the web interface is 99.99%.
    [Show full text]
  • List of NMAP Scripts Use with the Nmap –Script Option
    List of NMAP Scripts Use with the nmap –script option Retrieves information from a listening acarsd daemon. Acarsd decodes ACARS (Aircraft Communication Addressing and Reporting System) data in real time. The information retrieved acarsd-info by this script includes the daemon version, API version, administrator e-mail address and listening frequency. Shows extra information about IPv6 addresses, such as address-info embedded MAC or IPv4 addresses when available. Performs password guessing against Apple Filing Protocol afp-brute (AFP). Attempts to get useful information about files from AFP afp-ls volumes. The output is intended to resemble the output of ls. Detects the Mac OS X AFP directory traversal vulnerability, afp-path-vuln CVE-2010-0533. Shows AFP server information. This information includes the server's hostname, IPv4 and IPv6 addresses, and hardware type afp-serverinfo (for example Macmini or MacBookPro). Shows AFP shares and ACLs. afp-showmount Retrieves the authentication scheme and realm of an AJP service ajp-auth (Apache JServ Protocol) that requires authentication. Performs brute force passwords auditing against the Apache JServ protocol. The Apache JServ Protocol is commonly used by ajp-brute web servers to communicate with back-end Java application server containers. Performs a HEAD or GET request against either the root directory or any optional directory of an Apache JServ Protocol ajp-headers server and returns the server response headers. Discovers which options are supported by the AJP (Apache JServ Protocol) server by sending an OPTIONS request and lists ajp-methods potentially risky methods. ajp-request Requests a URI over the Apache JServ Protocol and displays the result (or stores it in a file).
    [Show full text]
  • 17 Basic Networking Clients
    Certification Basic Networking Clients UNIT 17 Basic Networking Clients 1 Rev RH033-RHEL3-1 Copyright © 2003 Red Hat, Inc. UNIT 16: Objectives ? Learn basic network commands ? Learn how to communicate securely with remote hosts ? Understand the use of rsync and wget 2 Rev RH033-RHEL3-1 Copyright © 2003 Red Hat, Inc. UNIT 17: Agenda ? ssh / scp / telnet ? lftp ? links ? mutt ? rsync / wget ? ping / traceroute / host 3 Rev RH033-RHEL3-1 Copyright © 2003 Red Hat, Inc. ssh: Secure Shell ? Public-key encryption technology replacement for various unsecure services ? Allows secure access to remote systems · $ ssh joe@barney -or- · $ ssh -l joe barney joe@barney's password: · $ ssh barney ls /tmp 4 Rev RH033-RHEL3-1 Copyright © 2003 Red Hat, Inc. scp: Secure copy ? Secure replacement for rcp ? Layered on top of ssh · $ scp source destination ? Remote files can be specified using: · user@host:/path/to/file · -r option enables recursion · -p preserves times and permissions · -C compresses datastream 5 Rev RH033-RHEL3-1 Copyright © 2003 Red Hat, Inc. telnet and the “r” services ? Insecure protocols ? telnet: Login names and passwords pass over the network in clear text ? “r” services (rsh, rlogin, rcp): generally insecure authentication mechanism ? telnet client can be used to connect to services running on arbitrary ports ? Example: testing your mail server: $ telnet localhost 25 6 Rev RH033-RHEL3-1 Copyright © 2003 Red Hat, Inc. lftp ? Versatile command-line FTP client ? Anonymous or real-user sessions $ lftp ftp.cdrom.com $ lftp -u joe ftp.myserver.com ? Automated transfers with lftpget 7 Rev RH033-RHEL3-1 Copyright © 2003 Red Hat, Inc.
    [Show full text]
  • Data Sheet FUJITSU CELVIN® NAS Q905 Storage
    Data Sheet FUJITSU CELVIN® NAS Q905 Storage Data Sheet FUJITSU CELVIN® NAS Q905 Storage Powerful 6-Drive NAS The FUJITSU CELVIN® NAS Server Q905 is the ideal product for file sharing, end to end backup options and SAN (Storage Area Network) integration for SMB customers - enabling centralized data management at a reasonable price. It is perfect for storing massive amounts of unstructured data or the management of virtual machines with scalability up to 36 TB and additional virtual disk expansion. Business Server Feature 6 hot swappable drives Integrated backup server with diverse replication modes iSCSI storage for cluster virtualization VMWare®/Citrix®/HyperV™ Capable Enabling private cloud Reliability Service-friendly cabinet 3-years spare part supply Country-specific warranty Top-up services are available Page 1 / 7 www.fujitsu.com/fts/accessories Data Sheet FUJITSU CELVIN® NAS Q905 Storage CELVIN® NAS Q905 Technical specifications Linux embedded system (2.6 kernel) Firmware based on 4.1.3 or higher Processor: Intel® Celeron® J1900 up to 2,41GHz Memory: 2 GB DDR3L RAM, one free slot, max up to 8GB 512 MB Flash on DOM FAN:2x quiet cooling fan (9 cm) Intel® Ethernet Controller I210-AT Formfactor: Tower Hard disk capacity Up to 6 x 2.5-inch or 3.5-inch SATA I/II/SATA 6Gb/s HDD or SSD up to 36TB raw capacity, consult HDD compatibility list NAS HDD: ready for 24x7 use; Business Critical HDD: tailored for 24x7 reliability LED USB Status HDD 1 -6 LAN Power System controls Power button, One-touch copy button, Alarm Buzzer (System Warning),
    [Show full text]
  • The Nmap Project
    Insecure.Org The Nmap Project Fotis Hantzis aka ithilgore sock-raw.org FOSSCOMM 2016 Insecure.Org whoami • Exploiting TCP and the Persist Timer Infiniteness (Phrack #66) • Abusing Network Protocols (stealthy portscanning through XMPP exploitation) • Nmap developer, Ncrack author • Startup ventures @ithilgore Insecure.Org http://phrack.org/issues/51/11.html#article Insecure.Org Ndiff NSE Npcap Zenmap Insecure.Org Trinity uses Nmap in Matrix Reloaded Insecure.Org CIA using Zenmap in Bourne Ultimatum Insecure.Org Die Hard 4 Insecure.Org And many more: http://nmap.org/movies Elysium Insecure.Org > 1000 students $5.000 stipends 3 – 4 months ~ 150 open source organizations Insecure.Org Past Nmap GSoC Accomplishments o Nping – generic packet crafting tool o Ncat – the modern netcat o Npcap – packet sniffing library (WPF) o Ncrack – network auth cracking tool o NSE – Nmap Scripting Engine o Zenmap – GUI for Nmap o Ndiff – diff for network scans Insecure.Org http://nmap.org/ncrack High speed network authentication cracking tool Insecure.Org Ncrack’s Main Features o Intelligent Core Engine o Service Recognition through Nmap (-oN, -oX) o Fine-grained timing control (cl, CL, to, cd, at, T1-T5) o Built-in username/password lists o Session stop/resume o Modular architecture o Nsock based (asynchronous) Insecure.Org Ncrack modules o SSH – custom opensshlib based on OpenSSH o RDP – extremely hard protocol by MS SMB o • Telnet o SIP • FTP • HTTP (basic/digest) • PostgreSQL • MySQL Contributions • VNC • POP3 • Redis Insecure.Org New Ncrack 0.5 release
    [Show full text]
  • Pragma Systems & Stay-Linked™: Remote SSH Connectivity Done Right
    WHITE PAPER Pragma Systems & Stay‐Linked™: Remote SSH Connectivity Done Right This paper is designed to serve as a primer for upgrading – or choosing and implementing – a highly effective, secure SSH connectivity solution. This document provides an overview of key regulatory and market developments driving the need to make remote computing systems more secure; takes a look at the origins of SSH and the factors that have led to its becoming the enterprise security protocol of choice; outlines key components of an optimal SSH‐based security approach; and, then, examines the market’s most trusted, effective, end‐to‐end, server and client SSH security solution, offered in partnership by Pragma Systems and Stay‐Linked. Pragma Systems & Stay‐Linked™: Remote SSH Connectivity Done Right Contents Executive Summary ............................................................................................................................................. 3 Takin’ it to the streets ......................................................................................................................................... 3 Clearly, it’s time to leave clear text behind ........................................................................................................ 4 Regulatory rundown ........................................................................................................................................... 4 Gaga for gadgets ................................................................................................................................................
    [Show full text]