Lỗi dòng lệnh lớn nhất? [đóng cửa]

Thiệt hại lớn nhất (dưới bất kỳ hình thức nào) mà bạn từng gây ra với một dòng lệnh sai lầm / nhầm lẫn / sai lầm là gì? Ví dụ, tôi đã xóa một cơ sở dữ liệu hệ thống sản xuất, nhưng tôi đã may mắn (tức là sao lưu) và không bị mất dữ liệu vĩnh viễn, mất tiền, thiệt hại tài sản, v.v.

Quan trọng nhất (đối với phiếu bầu), bạn làm gì để đảm bảo điều đó sẽ không bao giờ xảy ra nữa?

Trong máy chủ SQL, trên một hệ thống sản xuất:

update customer set password = '' <enter>

Bản sao lưu gần đây nhất giống như một tuần tuổi.

Để giảm thiểu điều này, bây giờ tôi thường viết một selectcâu lệnh trước để đảm bảo rằng tôi đã hiểu wheređúng mệnh đề, sau đó quay lại và chỉnh sửa nó để chèn setmệnh đề và thay đổi câu lệnh thành update.

Sai lầm lớn nhất? Nghĩ rằng tôi đã đặt hai biến khi tôi không có. Vì vậy, rm -rf $ VARIABLE / $ VARIABLE2 đã trở thành rm -rf /. FreeBSD gần đây đã cập nhật công cụ rm của họ để rm -rf / không thể thực hiện được nữa vì lỗi này!

shutdown -h now 

có nghĩa là cho máy trạm cục bộ, nhưng đã gõ nó trong khi đăng nhập qua ssh trên máy chủ sản xuất. Kể từ đó tôi luôn có tên máy chủ trong tôi $PS1.

Bỏ qua -r từ lệnh tắt máy. Trên một máy chủ từ xa. Ở phía bên kia của đất nước. Không có nhân viên CNTT trong văn phòng từ xa.

Tất cả chúng ta đã làm điều đó, nó gần giống như một nghi thức thông qua ở giai đoạn này.

Trên hệ thống VMS, tôi đã sử dụng lệnh ASSIGN DCL để gán tên logic và tôi muốn GHI LẠI một dòng lệnh ASSIGN trước đó. Bây giờ, trong VMS, bạn chỉ gõ bao nhiêu ký tự của một lệnh để làm cho nó rõ ràng. Vì vậy, tôi dự định gõ

REC

nhưng tôi vô tình gõ

REQ ASS

thay thế. REQ đủ rõ ràng cho lệnh REQUEST, nó phát ra đối số cho mọi người với các đặc quyền của nhà điều hành (đó là tất cả mọi người trong CNTT). Vì vậy, toàn bộ bộ phận đã nhận được tin nhắn quảng bá của tôi chỉ đơn giản là "ASS".

Trên hệ thống Solaris: "killall dataLoader".

'DataLoader' là một ứng dụng tôi đang làm việc. Trên Linux, killall hoạt động như pkill. Nó sẽ gửi tín hiệu đến các tiến trình khớp với một chuỗi được đưa ra làm đối số. Trên Solaris, killall trys để giết mọi thứ trên hệ thống mà người dùng hiện tại có thể giết. Tôi đã root

Một lần, nhiều lần trước đây, tôi cần tìm một chương trình thực thi cụ thể nhưng không thể nhớ tên đầy đủ của nó (nhưng có thể nhớ một vài chữ cái). Vì vậy, tôi nghĩ rằng tôi sẽ kiểm tra thư mục / usr / bin với cái gì đó như thế này

rm /usr/bin/i*g*

Lạ thật. Không có gì trở lại. Hình dung tôi vừa viết sai lá thư thứ hai, tôi đã thử lại với

rm /usr/bin/i*

Một lần nữa, không có gì. Sau khi làm tương tự với / usr / local / bin, / usr / sbin, và bất cứ điều gì khác mà tôi nghĩ nó có thể xảy ra, tôi nhận ra rằng tôi đã hiểu nhầm lệnh 'ls'.

Không biết bộ não xuất phát từ đâu, nhưng chắc chắn đó không phải là lỗi tôi từng mắc phải.

setup.exe

Đó là Windows Vista.

Cố gắng thay đổi quyền sở hữu mọi thứ trong một thư mục, bao gồm các tệp chấm, với:

chown -R user * .*

Đoán xem điều đó làm gì?

Để hủy / dev / sdb, may mắn thay, tôi đã có một bản sao lưu cập nhật tốt

dd if=/dev/urandom of=/dev/sda

select * from <File1> join <file2>

Trên một hộp sản xuất. Lưu ý thiếu một onđiều khoản. :-) Cả hai bảng là hàng triệu bảng hàng và đây là bảng AS / 400 vào giữa những năm 90 khi SQL chạy, bạn không thể giết nó.

Trên một trong những máy chủ sản xuất dữ liệu của chúng tôi, một trong những gốc của tôi đã gõ:

chmod -R 777 /

Bởi vì anh ta đã nhận được lỗi cấp phép với một số tập lệnh ...

Ngay sau đó, khóa riêng của anh ấy đã bị xóa khỏi tất cả các máy chủ và anh ấy đã chăm sóc khôi phục dữ liệu 1TB trên máy chủ sản xuất dữ liệu ...

Yêu thích của tôi là khi tôi ở trường đại học. Tôi đang xây dựng một ứng dụng (tôi không nhớ cái gì) và vì tôi không root nên tôi đã xây dựng nó bằng

PREFIX=~username/usr/local

Vì vậy, tôi có thể cài đặt nó vào thư mục nhà của tôi. Thật không may, nó được cài đặt vào

/home/username/src/app/~username/usr/local

thay thế. Tự nhiên để xóa nó như bắt đầu lại tôi thực hiện

rm -rf ~username

Trong thư mục nguồn.

Tôi tự hỏi tại sao nó lại mất nhiều thời gian như vậy ....

:-)

Tuy nhiên, điều tồi tệ nhất của tôi là khi tôi làm việc với máy trạm solaris và sau khi cài đặt xong, chúng tôi muốn xóa cấu hình sẵn sàng cho cấu hình trực tiếp. Vì vậy, tôi đã thực hiện

sys-unconfig

Đồng ý với thông báo cảnh báo và thay vì máy khởi động lại và quay lại "mặc định của nhà máy" Cửa sổ xterm nói đơn giản

connection closed by foreign host.

Đạo đức của câu chuyện Đừng bao giờ để một cái vỏ gốc mở trên một máy chủ khác! KHÔNG BAO GIỜ!!

Cách đây nhiều năm, tôi đã ở nhà viết mã lên một số thứ bằng php khi đang thực hiện một dự án với một người bạn của tôi, người duy trì dự án. Chúng tôi đã IM với nhau trong một nỗ lực hợp tác. Chúng tôi luôn nói đùa qua lại trong chơi.

Tôi đã cố gắng để ssh-agent hoạt động chính xác trên máy của mình trong khi chúng tôi đang có một cuộc chiến tôn giáo giữa Perl vs PHP. Sau đó, tôi đã đề cập một vài điều về ssh-agent cần phải được đánh giá (không biết tại sao tôi lại nói vậy). Vì vậy, sau đó anh ấy đã gửi cho tôi tin nhắn này trong một nỗ lực, vì vậy tôi nghĩ, để giúp tôi giải quyết vấn đề của mình (hãy nhớ rằng tôi đã được sử dụng để root):

\# eval $(echo ssh-agent | 
perl -pe 's/h-a/m -r/' | 
perl -pe 's/^ss/r/' | 
perl -pe 's/gent/f \//')

CẢNH BÁO! ĐỪNG CHẠY RỦI RO !!!

NẾU bạn loại bỏ eval và tự chạy lệnh bên trong:

rm -rf /

Tôi mất 4 giây để nhận ra chuyện gì đang xảy ra nhưng thiệt hại đã xảy ra. Tôi đã phải cài đặt lại hệ điều hành của tôi. May mắn thay, không có gì trong công việc của tôi bị xóa sổ ngoại trừ một số nội dung trong / etc iirc. Anh ấy đã cười rất lớn khi tôi gửi cho anh ấy một tin nhắn kinh dị hỏi tại sao anh ấy làm vậy. Chúng tôi là cả hai kỹ sư hệ thống dài hạn. Anh ấy đã không nghĩ rằng tôi sẽ chạy nó và sẽ cẩn thận hơn để kiểm tra nó trước khi chỉ đơn giản là tôi và tôi chỉ tin tưởng anh ấy nên tôi thậm chí không nghĩ rằng anh ấy đang chơi xung quanh. Không cần phải nói, câu chuyện nhỏ này xuất hiện mọi lúc giữa chúng ta. Vì vậy, tôi quyết định bất tử nó.

Làm thế nào tôi giảm thiểu điều này xảy ra một lần nữa? Tôi tin tưởng không ai!

Một câu chuyện ít thú vị hơn là một vài năm trước, tôi đã thực hiện một số công việc trong một hộp nhiệm vụ quan trọng trong công việc. Tôi đã có một vài điều khoản mở cho máy khác nhau. Tôi cần phải loại bỏ một số thứ không cần thiết trong một thư mục. Vâng, tôi đã bị lạc trong các điều khoản của tôi và vô tình rm'ed . trong thư mục địa phương của tôi nhưng trên máy chủ sai (thuật ngữ sai) !!. Tôi đã thực thi lệnh trong / var / lib / mysql thay vì / tmp trên máy chủ ứng dụng (thuật ngữ khác). Không cần phải nói, tôi xóa sạch cơ sở dữ liệu sản xuất. May mắn thay, chúng tôi đã có một chế độ chờ ấm áp mà chúng tôi đã gặp trong khi tôi và một đồng nghiệp đã xây dựng lại bản chính từ bản sao lưu và chế độ chờ. Điều đó mất khoảng 18 giờ để làm.

Giảm thiểu: cẩn thận hơn về những cửa sổ tôi thực hiện các lệnh trước khi thực hiện chúng.

phiên bản ngắn

#/bin/bash
$0&
$0

Tôi đã từng muốn xóa một loạt các tập tin trong một thư mục.

del *.*

Các máy tính sau đó nói: "Bạn có chắc chắn? [Y / N]" Tôi nghĩ "Đương nhiên tôi chắc chắn, tôi sẽ không có gõ lệnh darn trong khác! Sheesh máy tính ngu ngốc càu nhàu ..."

Y <enter>

C:\Windows>_

Ừm ... WTF? Có phải tôi vừa xóa thư mục windows của mình? ....

undelete *.*

Trong những ngày của các đĩa cứng nhỏ, tôi biết mọi tệp trong c: \ windows dùng để làm gì và tên của nó là gì, nhưng ngay cả sau khi xóa tất cả mọi thứ, hệ thống không bao giờ giống nhau. Tôi đã có được một chút tôn trọng cho lời nhắc "bạn có chắc không". Chỉ một chút.

Tôi nghĩ rằng điều ngu ngốc nhất mà tôi từng làm là để loại bỏ các tuyến đường mặc định trên ra bên ngoài cụm phải đối mặt với bức tường lửa - trong khi VPN'ed máy tính để bàn của tôi hơn một trăm dặm.

May mắn thay, đó là trong một khoảng thời gian được chỉ định là thời gian chết theo kế hoạch (chỉ trong trường hợp), nhưng điều đó không giúp tôi tiết kiệm được chuyến đi vòng 200 dặm để đi và cấu hình lại tường lửa tại chỗ. Điều này cũng không giúp ích gì cho việc này đã loại bỏ các hệ thống sản xuất tiếp xúc với internet của chúng tôi trong suốt thời gian tôi đi du lịch và sửa chữa sau đó.

Chúng ta đều biết định nghĩa của nano-giây. Một giây không còn nhỏ hơn nữa và là khoảng thời gian giữa việc nhấn 'nhập' và nhận ra lỗi lầm của bạn.

Đầu tiên của hai ...

Trên hộp Solaris, chúng tôi có bản sao lưu tar của máy AIX ..

Một trong những Nhà phát triển đã gõ:

tax xvf AIX_Backup.tar

Tất nhiên, các đường dẫn trong thuế là tuyệt đối và cuối cùng chúng tôi đã tạo ra một bản phân phối mới của unix ... Solarix ... Vấn đề duy nhất với bản phân phối là nó không khởi động :(

Câu chuyện kể với tôi:

Một chi nhánh khác được gọi bởi vì tổng đài địa phương của họ có một số vấn đề. Sau một số điều tra, chúng tôi biết rằng họ đã cập nhật máy chủ của họ, nhưng không phải cấu hình Asterisk của họ. Vì vậy, quản trị viên quyết định hướng dẫn anh chàng chi nhánh làm lại cấu hình.

Quản trị viên: "Ok, bây giờ, nhập rm -rf / etc / asterisk"

Chàng trai: "Ok."

Quản trị viên: "Bây giờ, nhập cp / var / ..."

Chàng trai: "Đợi đã, nó vẫn đang chạy ..."

Quản trị viên: ??? ... !!!

rm -rf / some/path 

thay vì

rm -rf /some/path 

May mắn thay, điều đó đã không xảy ra với tôi ;-)

source ~/.bash_history

Ý định của tôi là nguồn .bashrc, nhưng tôi quá vội vàng với việc hoàn thành tab ...

Một cái gì đó dọc theo dòng này:

sudo dd if=/dev/zero of=/dev/sda

Ý tôi là sda4. Tôi đã xóa toàn bộ đĩa, không chỉ phân vùng :-(

XCOPYlà một con quái vật mạnh mẽ - tàn nhẫn trong việc thực thi và bị trì hoãn bởi thực tế là dòng lệnh của nó lập luận ngược lại với Window COPYvà UNIX cp.

Vài ngày trước tôi vô tình viết:

xcopy src \path\to\a\new\nonexistent\directory

XCOPY đủ tử tế để ghi đè lên tôi src thư mục với ... không có gì! Và nó cũng không buồn đặt các tệp cũ vào thùng rác.

Ồ, và hóa ra là XCOPYthực sự ghi đè lên các lĩnh vực tương tự trên đĩa thay vì phân bổ các lĩnh vực mới. Tôi đã thử 3 chương trình khôi phục đĩa và chương trình tốt nhất chỉ có thể khôi phục 3 trong số 10 tệp bị mất. Tất nhiên 3 tập tin đó chỉ là vshost.exevà bạn bè của nó. Sưng lên!

gặp sự cố với mạng (trên máy từ xa) và chỉ muốn khởi động lại giao diện

ifconfig eth0 down && ifconfig eth0 upp

Ngày nay, tôi chắc chắn rằng ai đó đang ở gần máy trước khi thử những thứ như thế này (iptables cũng là một ứng cử viên tốt). Và khi không có ai ở đó, tôi đã từng gõ

sleep 600; reboot

vào một thiết bị đầu cuối (màn hình) khác, để nó khởi động lại nếu tôi không thể ctrl + c lệnh trong vòng 10 phút.

Tôi cũng đã học được từ sai lầm đó (ctrl + c, giấc ngủ sẽ chạy khởi động lại) và bây giờ tôi sử dụng

sleep 600 && reboot

Nó sẽ cho phép tôi ctrl + c nó.

ifconfig eth0 down

Rất tiếc, tôi ở bên ngoài của eth0. Máy chủ web ở phía bên kia của thế giới, trong một căn phòng bị khóa. Không có quyền truy cập mạng để đăng nhập hoặc khởi động lại. Tào lao

Một cookie miễn phí cho bất cứ ai có thể cho tôi biết lý do tại sao tôi là một thằng ngốc khi cố gắng xóa tất cả các tệp và thư mục ẩn:

rm -rf. *

Trong khi dọn dẹp thư mục nhà của tôi trên một máy chủ web sản xuất, tôi quên rằng tôi đã liên kết web root của máy chủ với một vị trí trong thư mục nhà của tôi. Không suy nghĩ, tôi đã chạy một rm -rf trên thư mục đó và điều tiếp theo tôi biết, mọi người đang gọi rằng trang web bị sập!

ÔNG!

Tôi đã từng so sánh dữ liệu trong hai thư mục và chạy rsync với tùy chọn -d (xóa các tệp ở đích không có trên nguồn). Và sau đó tôi đã chuyển xung quanh nguồn và đích khi tôi chạy rsync. Điều đó đã xóa tất cả các tập tin mới, mà tôi muốn sao lưu. Bây giờ tôi đã học chạy rsync với -n (chạy khô).

rsync -trvd --stats --progress /destination /source

Tôi không có bản sao lưu.

Ngày xửa ngày xưa (có lẽ là System III, nhưng đã lâu rồi), có thể tạo một tệp có tên *bằng cách sử dụng trích dẫn shell bên phải. Khi tôi tìm thấy một trong thư mục nhà của tôi, tôi đã gõrm * và ngón tay vào phím quay lại khi có gì đó khiến tôi do dự và nghĩ về nó ...

Tạo một tệp như vậy cho người dùng khác là một trò đùa phổ biến.

Nếu tập tin đang ngồi ở đó trong một thư mục, đó là một khó khăn để giảm thiểu. Phản xạ chỉ cần gõ tên của nó chính xác nhưls vừa hiển thị, nó khá mạnh.

Trò đùa khác (ít gây hại hơn) là đặt tên cho các tệp có khoảng trắng ở cuối (hoặc chỉ khoảng trắng) khó xóa hơn nhiều ...

Do một số kinh nghiệm tồi tệ với tính dễ vỡ của JBoss sau khi khởi động lại, tôi muốn xóa các tệp làm việc của JBoss trước khi khởi động lại. Tôi thường làm:

# cd /var/cache/jboss
# rm -rf tmp/* work/*

Để bảo vệ bản thân khỏi việc gõ bất kỳ lỗi nào trong số nhiều sai lầm tai hại có thể xảy ra, như:

• / tmp / *
• tmp / *
• bạn hiểu ý

Tôi thực hiện lệnh cuối cùng:

# sudo -u jboss rm -rf tmp/* work/*

Vì người dùng JBoss sẽ gặp khó khăn khi xóa bất kỳ tệp quan trọng nào không thuộc về nó.

Tôi chưa bao giờ thực sự mắc sai lầm đó, nhưng tôi an toàn trong trường hợp tôi làm.