This is my personal opinion based on working with LabCloud Inc (https://www.labcloudinc.com/) for about 5 years. It looked promising but for these years project did very little progress for a few resons:
* Both CEO and CTO (Charlie and Igor) are totally irresponsible. They don't take responsibility for their words at all. CTO also may behave dodgy, speak lies or twist things.
* Professional incompetence. This includes project management and technical decisions.
These lead to:
* As a matter of fact they never paid in time for the whole 5 years! Charlie just doesn't accept the fact it matters when exactly he'll pay. It's ok for him just to delay payment for 3 weeks and then he says 'so sorry' and the incident is over for him. When he doesn't want to take responsibility he's just unreachable. Playing busy. Also have a big mouth when it comes to speak of him self (and the company).
* Total inability to meet deadlines. This is just painful to deal with. Both CEO and CTO just can't do it. If they plan something they always fuck up and then blame each other or someone else. It's just toxic.
* All 5 years the project is on the edge of being profitable due to funny business model. Yet CEO does regular air trips and seems like making money just fine.
* Weak technical side. Technical leader Igor just has nor enough skill, nor he wants to develop it. For example being a lead developer he doesn't if SSL encrypts transmitted URL or not. When doing a simple 'for loop' he takes the most ineffective approach. Can't think consistent. Do you imaging that??! All he does is googling like a mad and then making a spaghetti code to meet so called deadlines or to please someone. Fixing that code then takes more time then doing it right from the start. Side blaming is also a common practice.
So in conclusion I want to warn you. If you have a choice to deal with LabCloud or not think twice.
Sunday, December 29, 2019
Thursday, December 13, 2018
FreeBSD NFSv4 mount of Windows 2019 Server share with Kerberos auth
Windows part:
Step 0: Ignore this complicated bullshit here https://docs.microsoft.com/en-us/previous-versions/msp-n-p/ff649429(v=pandp.10) No reason of using SPN. It only adds some kind of proxy but no security. Go to Step 1.
Step 1: Install NFS server on Windows as described on the web, create share folder.
Step 1.1: Windows NFS server's log location is this: Event Manager, Services and Applications, Microsoft, ServicesForNFS-Server (no idea, why it's written like that)
Step 2: Use this configuration for network share
Step 3: From powershell execute this to enable mapping via AD:
Set-NfsMappingStore -EnableADLookup $true |
Step 4: Probably restart is required.
FreeBSD part:
Step 0: FQDN?
Step 1: Install pam_krb5 (linked with MIT in my case)
Step 2: Install /etc/krb5.conf (pretty ordinary, lot's of examples in the Internet, but notice tkt_enctypes). Also in FreeBSD pam section is commented because it pam ignores it by some reason anyway.
[libdefaults] default_realm = DOMAIN.LOCAL forwardable = true# default_cc_name = /tmp/krb5cc_%{uid} default_tkt_enctypes = aes256-cts-hmac-sha1-96[appdefaults] default_realm = DOMAIN.LOCAL# pam = { forwardable = true krb4_convert = false debug = true ccache = FILE:/tmp/krb5cc_%u ticket_lifetime = 36000 renew_lifetime = 36000# }[realms] DOMAIN = { kdc = sun2.domain.local:88 kdc = sun2.domain.local:88 admin_server = sun2.domain.local:749 kpasswd_server = sun2.domain.local:464 kpasswd_protocol = SET_CHANGE default_domain = domain.local }[domain_realm] domain.local = DOMAIN.LOCAL .domain.local = DOMAIN.LOCAL .DOMAIN.LOCAL = DOMAIN.LOCAL[logging] default = FILE:/var/log/krb5lib.log# kdc = FILE:/var/log/krb5kdc.log# admin_server = FILE:/var/log/kadmind.log# default = SYSLOG:INFO:USER |
Step 3: Check that you can get your ticket with kinit.
Step 4: Uncomment krb5 sections where you need it in /etc/pam.d/* to login. Note: that login via ssh and getting ccache file is broken on FreeBSD 11.2. Try other methods to verity that you get your ticket in the default /tmp/krb5* location.
Step 5: These services used for UNIX/AD user mapping. Enable and start them. The last one probably isn't required.
# kerberos gssd_enable="YES" nfsuserd_enable="YES" #nfscbd_enable="YES"
Step 6:
mount -o sec=krb5,minorversion=1,nfsv4 sun3.domain.local:/nfs_share_test1 /mnt/
Mounted file's permissions will be shown as 'nobody:nobody' cause FreeBSD can't resole Windows users and groups on it's side. Despite this mapping the real permission still be respected and access on UNIX box checked via Kerberos ticket.
Though Windows set ownership differently depending if the user is in Domain Administrator (or Administrators?) group. It was possible to change on old Windows (pre 2008?) but not now.
So this link is irrelevant.
Sunday, October 7, 2018
оптимак цф, инструкция
https://drive.google.com/file/d/1PTBt5iPvFGCqQ9djJ8mQ6eUQFfoe7o3q
похоже, я первый в инете догадался ее выложить в долговременное хранение. сканировал не я, претензии по качеству не ко мне.
Tuesday, September 4, 2018
clGetPlatformIDs(): CL_PLATFORM_NOT_FOUND_KHR in chroot
memo
* First search for opencl_runtime_16.1.2_x64_rh_6.4.0.37.tgz in obsolated Intel drivers. The newer version didn't worked.
* Then sh NVIDIA-Linux-x86_64-361.45.11-no-compat32.run --no-x-check --no-kernel-module-source --no-kernel-module -N This installs file here /etc/OpenCL/vendors and relative path didn't work, so I changed to full: /usr/lib64/libnvidia-opencl.so.1 (no '\n' at the end)
* rm /etc/alternatives/opencl-libOpenCL.so*
* run nvidia-cuda-mps-control -d (without chroot?) to have a fresh ~/.nv/ cache
* clinfo now shows two devices
* hashcat now benchmarks with two devices turn on with -D1,2
* but warning nvmlDeviceGetCurrPcieLinkWidth(): Not Supported etc shows and this brakes on a real task.
* hashcat complains about Outdated or broken NVIDIA driver detected! time to update driver.
* First search for opencl_runtime_16.1.2_x64_rh_6.4.0.37.tgz in obsolated Intel drivers. The newer version didn't worked.
* Then sh NVIDIA-Linux-x86_64-361.45.11-no-compat32.run --no-x-check --no-kernel-module-source --no-kernel-module -N This installs file here /etc/OpenCL/vendors and relative path didn't work, so I changed to full: /usr/lib64/libnvidia-opencl.so.1 (no '\n' at the end)
* rm /etc/alternatives/opencl-libOpenCL.so*
* run nvidia-cuda-mps-control -d (without chroot?) to have a fresh ~/.nv/ cache
* clinfo now shows two devices
* hashcat now benchmarks with two devices turn on with -D1,2
* but warning nvmlDeviceGetCurrPcieLinkWidth(): Not Supported etc shows and this brakes on a real task.
* hashcat complains about Outdated or broken NVIDIA driver detected! time to update driver.
Subscribe to:
Posts (Atom)
