CPYNET

Kullanım Senaryoları

CPYNET'in gerçekten inşa edildiği beş senaryo - varsayımsal değil. Aşağıdaki her komut gerçek bir deployment'a karşı çalıştırılan gerçek bir girdi, ürettiği tam çıktıyla birlikte gösteriliyor.

SSH oturumundan log paylaşma

Bir sunucuya SSH ile bağlısın, bir şey patladı, ve ilgili log satırlarını hemen bir ekip arkadaşına ulaştırman gerekiyor - ikinci bir SSH erişimi ya da dosya e-postalamak olmadan.

sen, sunucuda
$ journalctl -u myservice -n 200 | cpy482913curl "https://llmtag.com/482913"

İki satır döner: çıplak kod ve hazır bir curl komutu. Hangisini sohbete yazarsan yaz - okuyan kişi tam metni alır, ve okuduğu an kalıcı olarak silinir:

ekip arkadaşın
$ pst 482913Aug 08 14:02:11 myservice[1823]: connection refused: db.internal:5432Aug 08 14:02:11 myservice[1823]: retrying in 5s...Aug 08 14:02:16 myservice[1823]: connection refused: db.internal:5432

Bu, pst shell fonksiyonu - yan etki olarak metni panosuna da bırakır, sadece bir kolaylık. Karşı tarafta cpy/pst kurulu değil mi? cpy'nin yukarıda bastığı düz curl "https://llmtag.com/482913" satırı da alias gerektirmeden aynı işi görür. Her iki durumda da aynı kodu (sen dahil kim olursa olsun) ikinci kez okumaya çalışmak 404 döner - zaten gitmiştir.

Panosu (clipboard) kapalı bir makineden metin taşıma

Bazı ortamlar - kilitli kurumsal dizüstüler, VDI oturumları, host ile guest arasında paylaşılan panosu olmayan uzak masaüstleri - işletim sistemi panosu üzerinden metin çıkarmana hiç izin vermez.

kilitli makine
$ echo "wifi parolası: correcthorsebatterystaple" | cpy174205curl "https://llmtag.com/174205"
kendi makinen, birkaç dakika sonra
$ pst 174205wifi parolası: correcthorsebatterystaple

CPYNET kilitli makinede işletim sistemi panosuna zaten hiç dokunmuyor - her şey curl üzerinden düz metin olarak çıkıyor, bu yüzden orada kapalı bir pano önemli değil. Metni geri okuyan makine normal bir makine, o yüzden pst'nin pano kolaylığı orada sorunsuz çalışır. Okuyan tarafta terminal yoksa: gönderdikten sonra çıkan QR kodunu telefonunla tara, doğrudan tarayıcıda açılır.

Teknik olmayan bir ekip arkadaşına parola korumalı bir link vermek

Paylaşman gereken herkes komut çalıştırmak istemez - bir müşteri, bir yönetici ya da kilitli bir makinedeki bir ekip arkadaşının tek ihtiyacı bir link ve tarayıcıda bir kere yazacağı bir parola.

sen
$ echo "staging: https://staging.internal  kullanıcı: demo  parola: xQ9!vB2m" | cpy -password=handoff2026591042curl "https://llmtag.com/591042"

Düz linki (tek başına kod yetmez - kodun kendisi doğru URL'e ihtiyaç duyar) ve parolayı ayrı kanallardan gönder. Karşı taraf linki herhangi bir tarayıcıda açar, sayfadaki alana parolayı yazar ve bir kere okur - CLI yok, tarayıcı eklentisi yok, hesap yok. Yanlış parola okuma hakkını tüketmeden başarısız olur; parola girilmezse yalnızca tekrar sorar.

Container'dan host'a çıktı aktarma

Paylaşılan volume'u olmayan bir container, izole bir build adımı, bir CI işinin ara çıktısı - stdout'a erişilebilen ama dosya sisteminin sonucu gerçekten ihtiyacın olan yerle paylaşmadığı her yer.

container'ın içinde
$ docker run myimage some-command | curl --data-binary @- https://llmtag.com/https://llmtag.com/718234

Düz bir pipe (container içinde cpy kurulu değilse) sadece çıplak URL'i döner - yine tek satır, yine bir sonraki adıma pipe'lanabilir:

host'ta
$ pst 718234{"status":"ok","records_processed":48213}

Container'da cpy kurulu değildi, o yüzden düz bir pipe'a düştü - kendi makinende neredeyse kesin kurulu, o yüzden geri okumak sadece pst. Kurulu değilse düz bir curl "https://llmtag.com/718234" de aynı işi görür. kubectl exec ile de aynı şekilde çalışır, curl'ün bile bulunmadığı minimal bir scratch/distroless imaj ile de (bkz. netcat fallback), ya da güvenilir bir şekilde erişebildiğin tek şeyin bir pipe olduğu herhangi bir ortamda da.

CLI'dan uçtan uca şifreli paylaşım

Yukarıdaki parola (-password=) sunucu tarafında kontrol edilir - sunucu metni doğrulamak için anlık olarak görür. cpy -e farklı, daha güçlü bir katman: şifreleme tamamen kendi makinende, hiçbir şey gönderilmeden önce yapılır, sunucu yalnızca şifreli metni saklar.

sen, istemci tarafında şifreliyorsun
$ echo "root ssh parolası: Tr0ub4dor&3" | cpy -e305817curl "https://llmtag.com/305817"key (share separately, never with the link/code): n8xQ2vLKw+9fZTa3mPqR7yUvXsB4tCdE

Kodu bir kanaldan, anahtarı başka bir kanaldan gönder (bir arama, ayrı bir sohbet, yüz yüze) - yalnızca linki ya da kodu olan biri okunamaz şifreli metin alır, sunucu dahil.

hem kodu hem anahtarı olan kişi
$ pst 305817 -key=n8xQ2vLKw+9fZTa3mPqR7yUvXsB4tCdEroot ssh parolası: Tr0ub4dor&3

-key= vermezsen pst ham şifreli metni basar - sunucunun anahtarla ya da anahtarsız onu çözecek bilgisi zaten hiç yoktur.